At 19:21 22.07.99 -0400, you wrote:
>The unit does not send out 8K worth of data at a shot. It sends out 64 bytes
>at a shot. The loads are of various sizes, on 64 byte boundries. Some loads
>are bigger than others, and yank data from all over the place and not in
>order either I don't think.
I know that the SC doesn't load 8kb at a time. To write data to a 2kb
SC-RAM bank it has to be put at $F000-$F7FF, or you might collide with the
hotspot for bankswitching at $FFF8. Also the SC has to load around the
loading routine, if it wants to leave that intact. Therefore it only
loads several sets of 64 byte blocks at a time.
What I meant was that the SC fills it entire 6kb of RAM with new code
before it starts executing it. You mentioned that the demo unit has
eight 8kb ROMS in it. So I thought that one of those 8kb ROMS holds
6kb worth of data plus some maintainance data for the BIOS code in
the demo unit. The code in the loading routine that sets the output
line low and imediately high again gets executed only once at the
beginning, so I thought it might tell the demo unit to switch to the
next 8kb ROM in it and serve 6kb worth of data from there.
>See above. The test is to check if this is the last block of data or not.
>Also, the demo unit has to queue up the next block of data so the 2600 has
>to wait for this. (there's no need for the queueing, but they were extremely
>power-concious and thought the 2600 couldn't supply more than like 2ma of
>current).
No, the check if there is more data to load or not is handled differently.
But you are right. There is no 65th byte as I first assumed. The demo unit
just sets the joystick button line high as long as it is preparing the
next 64 byte block. The delay loop for this was what confused me. I now
think that setting the output line low, wait for 12 6507 processor cycles
and then set the output line high again triggers the start of the
transmission of the current 64 bytes block.
>I would like to see it. I had a hard time extracting the code and commenting
>it myself and would like to see how someone else did it.
>(especially all those checks before it does the loading proper)
I'm not quite sure which checks you mean, but I'll post the code in
a different message, so that you can have a look at it. If you want
to comment on or correct anything of it, please feel free to do so.
>I doubt they would be easily convertable due to the way they are loaded,
>though they might be able to be changed. nope I haven't put it up yet since
>I already boxed it up before I had a chance to read the EPROMs. I only have
>the image to EPROM #1 (which was the one I replaced).
If this is the data that gets loaded first from the bootstrap code,
I'd like to have a look at it. Writing a PC program that can convert
the ROMs into an emulator friendly binary, which then can be converted
into SC audio data, shouldn't be too hard. The only problem is to
figure out how the 64 bytes blocks are stored in the EPROM. Wheter it
is in the order that the demo unit has to serve them or the order they
have to appear in the SC-RAM. Or maybe it's somthing completely
different.
Note to Russ or Lee: Would you be willing to lend your demo unit to
Kevin again, so that he can read out the EPROMS, if we can figure
out how to convert them to the SC tape format?
Ciao, Eckhard Stolberg
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
