Forum unknown
· Help/Announcements
#uploading
17 messages in this thread
Bela,
I'm guessing that OnLine! is able to recover from an error during the
transfer while Ahost can't so that explains the no-crash vs crash. As far as
the explicit call to CIS — back a few years ago when B Protocol became
available for the Atari 800 series, they had the same problem…so I do suspect
CIS may have some fault in the bad uploads.
Don
If they put it in ROM, they will surely allow you to boot KickStart off a
floppy as well. That's just common sense. However, the idea of having a ROM
as well as the KS RAM is new to me. 256K of RAM is not a big expense, but I'm
not sure about the circuitry that allows it to be write-protected. (Seems
pretty simple, but what do I know). So maybe they've gotten rid of the WCS
daughterboard, and just added another 256K to the standard memory, with the
write-protect hardware, and the ROM. Yes, then you could boot ROM to WCS RAM,
and then as the disk-resident part loaded, it could patch the WCS copy of the
ROM as necessary. A neat way to have patchable ROM.
Or how about this: 256K of battery-backed RAM. No ROM. You have to use the
KickStart disk the first time you boot the machine (unless it's done at the
factory), but then it isn't needed again until you get a new version of KS.
Now that would be >nice<… – Bela
Bela,
Aren't guessing games fun! <grin> I was speculating, and I do see one
obvious problem….the daughter board takes up one of the ROM sockets (which
socket I presume would be needed for the OS ROMs) so we are really left with
the ST style OS, you can have it in RAM, but lose 256K or you can have it in
ROM and have full memory. Even with the ST's OS (TOS) in ROM, you can boot up
the TOS disk and load the OS from disk…but do lose the RAM.
One other somewhat obvious solution is to not offer the ROM upgrade to
A1000 owners, but keep that OS on disk and put the ROM's only in upgrade
machines. I mean Hazy did say "Not what everyone thinks………..
Don
There's no simple way to have both ROM and WCS RAM in an A1000 board. And
they've done a revised A1000 board that has WCS down on the main board, and
no ROM slots. I don't know if that's what's actually shipping, but if it
is that would really close the issue for a widespread modification of A1000
machines to use ROM instead of RAM. The ROM is likely to appear in a
future machine; possibly all future machines. And there's been a proposal
to also sell a WCS card as an add on for those with a new machine that want
WCS instead of ROM.
Though I'm sure any new Amiga system will have more than the 256K base of
the A1000, especially since we've pretty much established 512K as a minimal
setup for any useful multitasking. But unlike our friends over in ST land,
its a small matter to replace alot of the ROM Kernal routines with disk
loaded routines.
I know that this can be done on a library-by-library basis, so any interm
upgrades between major ROM releases could be via a few libraries, not the
whole 256K of ROM Kernal. Any major revision COULD be upgraded with a new
set of ROMs.
The thing I don't like about a ROM locked ROM Kernal, however, is that it
makes a software upgrade more difficult to achieve. If we make the 1.2
workbench and kickstart disks free upgrades, or even charge for cost of
materials, most everyone will go out, pop in the new Kickstart, and be on
their way.
And with the overwhelming prevalence of 1.2 over 1.1 (hasn't happened yet,
waiting on that FINAL release…), 1.1 becomes a thing of the past. If
everyone had to open their machines and swap ROMs, it would take much
longer for updates to be globally in place, and the percentage of holdouts
could be large enough to form a critical mass. At this point, developers
would write for both systems, avoiding any enhancements in the new system.
-Hazy
There's no simple way to have both ROM and WCS RAM in an A1000 board. And
they've done a revised A1000 board that has WCS down on the main board, and
no ROM slots. I don't know if that's what's actually shipping, but if it
is that would really close the issue for a widespread modification of A1000
machines to use ROM instead of RAM. The ROM is likely to appear in a
future machine; possibly all future machines. And there's been a proposal
to also sell a WCS card as an add on for those with a new machine that want
WCS instead of ROM.
Though I'm sure any new Amiga system will have more than the 256K base of
the A1000, especially since we've pretty much established 512K as a minimal
setup for any useful multitasking. But unlike our friends over in ST land,
its a small matter to replace alot of the ROM Kernal routines with disk
loaded routines.
I know that this can be done on a library-by-library basis, so any interm
upgrades between major ROM releases could be via a few libraries, not the
whole 256K of ROM Kernal. Any major revision COULD be upgraded with a new
set of ROMs.
The thing I don't like about a ROM locked ROM Kernal, however, is that it
makes a software upgrade more difficult to achieve. If we make the 1.2
workbench and kickstart disks free upgrades, or even charge for cost of
materials, most everyone will go out, pop in the new Kickstart, and be on
their way.
And with the overwhelming prevalence of 1.2 over 1.1 (hasn't happened yet,
waiting on that FINAL release…), 1.1 becomes a thing of the past. If
everyone had to open their machines and swap ROMs, it would take much
longer for updates to be globally in place, and the percentage of holdouts
could be large enough to form a critical mass. At this point, developers
would write for both systems, avoiding any enhancements in the new system.
-Hazy
Bela,
Aren't guessing games fun! <grin> I was speculating, and I do see one
obvious problem….the daughter board takes up one of the ROM sockets (which
socket I presume would be needed for the OS ROMs) so we are really left with
the ST style OS, you can have it in RAM, but lose 256K or you can have it in
ROM and have full memory. Even with the ST's OS (TOS) in ROM, you can boot up
the TOS disk and load the OS from disk…but do lose the RAM.
One other somewhat obvious solution is to not offer the ROM upgrade to
A1000 owners, but keep that OS on disk and put the ROM's only in upgrade
machines. I mean Hazy did say "Not what everyone thinks………..
Don
If they put it in ROM, they will surely allow you to boot KickStart off a
floppy as well. That's just common sense. However, the idea of having a ROM
as well as the KS RAM is new to me. 256K of RAM is not a big expense, but I'm
not sure about the circuitry that allows it to be write-protected. (Seems
pretty simple, but what do I know). So maybe they've gotten rid of the WCS
daughterboard, and just added another 256K to the standard memory, with the
write-protect hardware, and the ROM. Yes, then you could boot ROM to WCS RAM,
and then as the disk-resident part loaded, it could patch the WCS copy of the
ROM as necessary. A neat way to have patchable ROM.
Or how about this: 256K of battery-backed RAM. No ROM. You have to use the
KickStart disk the first time you boot the machine (unless it's done at the
factory), but then it isn't needed again until you get a new version of KS.
Now that would be >nice<… – Bela
It sounds like there may be an error or ambiguity in one of CIS' B-protocol
documents, that causes people to write different programs that bomb in the
same way. I know "B" does work correctly all the time with some programs
that support it. I'll see if Chuck Forsberg knows anything about it… –
Bela
If you'll be talking to Chuck Forsberg, be sure to ask him when Pro-YAM
will be out for the Amiga. 😉
P.S. I use /slant/ for italics as well — and more often than _underline_ or
>boldface< since the / character is "lower case", saving wear and tear on the
little finger.
If you'll be talking to Chuck Forsberg, be sure to ask him when Pro-YAM
will be out for the Amiga. 😉
P.S. I use /slant/ for italics as well — and more often than _underline_ or
>boldface< since the / character is "lower case", saving wear and tear on the
little finger.
The B protocol code I use (not on my Amiga) is adapted from a procedure I
got from a Borland DL. It has worked flawlessly on both directions so I
believe as you do that CIS and B protocol aren't to blame. However, besides
converting Turbo Pascal to UCSD I made a lot of mods to the error recovery
code which I found to be very lax. Whoever wrote that procedure didn't stop
to look at his code when he finished to think through what would happen in
various error situations. Sounds like maybe the Amiga implementors stopped
too soon as well. I could upload the code if anyone is interested. It's a
UCSD Pascal procedure to be called by a terminal program whenvever an enq
is received (05). It handles a complete B protocol transfer and then
returns to the caller.
The B protocol code I use (not on my Amiga) is adapted from a procedure I
got from a Borland DL. It has worked flawlessly on both directions so I
believe as you do that CIS and B protocol aren't to blame. However, besides
converting Turbo Pascal to UCSD I made a lot of mods to the error recovery
code which I found to be very lax. Whoever wrote that procedure didn't stop
to look at his code when he finished to think through what would happen in
various error situations. Sounds like maybe the Amiga implementors stopped
too soon as well. I could upload the code if anyone is interested. It's a
UCSD Pascal procedure to be called by a terminal program whenvever an enq
is received (05). It handles a complete B protocol transfer and then
returns to the caller.
Bela– The B protocol code I use (not on my Amiga) is adapted from a procedure
I got from a Borland DL. It has worked flawlessly on both directions so I
believe as you do that CIS and B protocol aren't to blame. However, besides
converting Turbo Pascal to UCSD I made a lot of mods to the error recovery code
which I found to be very lax. Whoever wrote that procedure didn't stop to look
at his code when he finished to think through what would happen in various
error situations. Sounds like maybe the Amiga implementors stopped too soon as
well. I could upload the code if anyone is interested. It's a UCSD Pascal
procedure to be called by a terminal program whenvever an enq is received (05).
It handles a complete B protocol transfer and then returns to the caller.
Tom
Bela– The B protocol code I use (not on my Amiga) is adapted from a procedure
I got from a Borland DL. It has worked flawlessly on both directions so I
believe as you do that CIS and B protocol aren't to blame. However, besides
converting Turbo Pascal to UCSD I made a lot of mods to the error recovery code
which I found to be very lax. Whoever wrote that procedure didn't stop to look
at his code when he finished to think through what would happen in various
error situations. Sounds like maybe the Amiga implementors stopped too soon as
well. I could upload the code if anyone is interested. It's a UCSD Pascal
procedure to be called by a terminal program whenvever an enq is received (05).
It handles a complete B protocol transfer and then returns to the caller.
Tom
It sounds like there may be an error or ambiguity in one of CIS' B-protocol
documents, that causes people to write different programs that bomb in the same
way. I know "B" does work correctly all the time with some programs that
support it. I'll see if Chuck Forsberg knows anything about it… – Bela
It sounds like there may be an error or ambiguity in one of CIS' B-protocol
documents, that causes people to write different programs that bomb in the same
way. I know "B" does work correctly all the time with some programs that
support it. I'll see if Chuck Forsberg knows anything about it… – Bela
It sounds like there may be an error or ambiguity in one of CIS' B-protocol
documents, that causes people to write different programs that bomb in the
same way. I know "B" does work correctly all the time with some programs
that support it. I'll see if Chuck Forsberg knows anything about it… –
Bela