| |
oziphantom
Registered: Oct 2014
Posts: 490 |
SD2IEC fastloader
Does anybody know of a system that fast loads, or a disassembly of a fast loader that SD2IEC supports? |
|
... 57 posts hidden. Click here to view all posts....
|
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
all valid however I would counter
- 1571 auto-boot is rather slow.
Not the 128 auto boot, but the disk loading to its RAM, and yes its slow, but is it slower than the time from the user closing the disk handle and then typing RUN"* and pressing return in most cases? Or does the delay it causes after the user types run"* cause it to take longer then the run"* command instructing the drive to do its install?
- Interleaving GCR read/decode and transfer implies no interruptions/DMA on the host side, which also implies screen off. (Pretty sure the byte-received detection and buffering is ruled out due to reasons.)
Maybe its due to clocks, however maybe you could make it buffer a couple of bytes up front and then make it always read from the buffer, which removes the "check if I need to use buffer" penalty. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Certainly worth some investigation.
As for autoboot, not sure if the boot block has provisions to load stuff into drive RAM, but when booting a C-128 program, yeah, why not also load stuff into drive RAM in the same boot procedure.
Problem however, is that you cannot load into the entire RAM, unlike the old two-stage "upload from host computer" technique. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
the autoboot drive is very well hidden. The 1571 manual mentions it in passing. For details you need the Abacus 1571 internals book, section 3.1.5 (p99 in my copy), it's a custom USR file ( which can't be made with BASIC 7 commands and needs BASIC 3 XD ), you can chain the USR blocks together to load as many 255 blocks as you want, each block has its own "destination address" and size if you want to load smaller parts to various parts of Drive RAM. However reading it in detail now, it doesn't sound like it actually autoboots it, and you have to issue a open 1,8,15"&filename" command to which it will then load the USR file into drive ram and start executing it. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Sounds like the old "utility loader" feature, which is already present in 1541.
For the C-128 target of my loader (where i've added burst support), i did implement autoboot of the test application using the bootblock, but i can't find the reference of the bootblock layout right now.
So no idea atm whether the bootblock can also load stuff to drive RAM. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
*= $b00
.text "cbm" ; Autoboot signature.
.word $0000 ; Load address for additional sectors. (T1, S1)
.byte $00 ; Bank number for additional sectors.
.byte $00 ; Number of sectors to load.
.text "dropzone", $00 ; Boot message: "BOOTING..."
.text "boot", $00 ; Program to load on boot.
jmp $1c0e
.align $100,0
I though there was something else as well from memory. in the the 128 auto boot uses T1 S0 and there was another autoboot system that used T0 or T2 or something like that, but it might be the 1581. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting oziphantomthe 512K cart will already be compressed. It will have some code uncompressed to do the initial boot etc, but all the data will be compressed.
How is this 5-6 sides then? 512K is only 3*683 blocks, so 512k only takes more than 3 sides if you reserve space for pesky things like directories and track/sector links, surely? |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
If you do file packing and use partial blocks, then sure. However when you factor in partial blocks + the loader code + side detection code + what disk is that file on data, it would push you to 4 sides. So you could probably squeeze it onto 4, but usually in such cases its better to keep a stash of common data on each side to limit the amount of flipping you need to do, and hence you start to spill into 5/6 sides. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
As you support SD2IEC (and a build running from a cartridge), do you also plan for REU support?
Should be fairly simple to either pre-load everything before the game, or load an entire disk/side once it's inserted for the first and last time, or cache every file once it's loaded for the first and last time. :) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
REU is the backup strat. In that it will get 1541UII users and TC(I think), but most people don't have access to a REU (and even the it will need the 1750 version if they have hardware.), so SD2IEC is the wider net option. The REU will also allow me to greatly speed up the map scrolling(I'm using bitmap) on the C64 version, which would be nice. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting oziphantom... when you factor in partial blocks + the loader code + side detection code + what disk is that file on data, it would push you to 4 sides. So you could probably squeeze it onto 4, but usually in such cases its better to keep a stash of common data on each side to limit the amount of flipping you need to do, and hence you start to spill into 5/6 sides.
Ah, that makes sense. Thank you. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
