Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > SD2IEC fastloader
2019-02-19 15:51
oziphantom

Registered: Oct 2014
Posts: 478
SD2IEC fastloader

Does anybody know of a system that fast loads, or a disassembly of a fast loader that SD2IEC supports?
2019-02-19 16:10
MagerValp

Registered: Dec 2001
Posts: 1055
Sure, at least Dreamload, ULoad M3, and eload.
2019-02-19 18:45
cadaver

Registered: Feb 2002
Posts: 1153
Or license the Sam's Journey loader now that it's supported, if a 2-bit ATN-loader is OK for you :)

(not sure if it can be made to run a different game without changing the drivecode such that the checksum no longer matches)
2019-02-19 18:57
Knight Rider

Registered: Mar 2005
Posts: 114
Fileload V2.1.2

It is not a fastloader for sd2iec, but is a fastloader for many drives and supports sd2iec.
2019-02-19 20:11
cadaver

Registered: Feb 2002
Posts: 1153
Is Fileload so that it detects a non-fastloader supported drive (SD2IEC, IDE64..) and installs a Kernal fallback? In that case it might not be what OP requires, as music / IRQs cannot run reliably.
2019-02-20 07:10
oziphantom

Registered: Oct 2014
Posts: 478
indeed, I want fastload, preferably screen on and only SD2IEC, in that I would strip out all the other drive versions.

In that the SD2IEC is fast, well a LOT faster than a physical drive, so while I was going to be "cart only", the ability for me to put all the files into 1 directory on the SD2IEC means I don't have to deal with "Insert disk 3 side A"....."Insert disk 2 side B" ... game runs for a bit.. "Insert disk 1 side B" etc I can just pull any file as I please. Since there is no seek time plus a fastloader the pause while the SD2IEC pulls in data might not be "unlivable" for the cheap people/people who won't remove a 1541IIu/need a TC for VGA output from their machine ;)

Sam's loader, interesting idea, I will need to ask Chester about it.
2019-02-20 21:05
Claus_2015

Registered: Oct 2012
Posts: 53
eload is the way to go for an sd2iec-only, smallest possible fastloader. You only need to send the string "eload" as drive code and off you go.

It is built into the sd2iec kernal (https://csdb.dk/release/?id=159050, source code is part of the zip), but as it is a kernal it is not superduper readable unfortunately. All relevant routines have "eload" in their name afair.
2019-02-20 21:27
Krill

Registered: Apr 2002
Posts: 2804
Quoting oziphantom
indeed, I want fastload, preferably screen on and only SD2IEC, in that I would strip out all the other drive versions.
Is that for a planned release of yours or just to play around for yourself?

Just asking because i think supporting SD2IEC and only that is quite a terrible idea.
Using the suggested "eload" after detecting SD2IEC but regular fastload for regular realdrives, otoh, would be pretty neat.

Claus_2015: Is eload capable of IRQ-loading? :) Because if so, could simply use that for my loader and scratch the old "add support to SD2IEC firmware" from my to-do list.
2019-02-20 22:02
cadaver

Registered: Feb 2002
Posts: 1153
Claus_2015: thanks for the hint, eload is .. interesting :) Practically you setup loading first with the stock routines, then upload the short "drivecode" and resume with a fast protocol.

It's a 2bit timed protocol, so you can't have sprites and IRQs will be delayed while it waits for badline clearance, but screen can be on, so would be OK for typical games.
2019-02-21 07:02
oziphantom

Registered: Oct 2014
Posts: 478
This will be for a release. The game is "Cart only" basically. However there are people who have what I call "Welded devices" attached to their machines, and they are welded in. Since the game is Gmod2, it won't work on anything but hardware or VICE. For the Mini one can just make it a Ocean 512K cart and pop up a screen that says "take snapshot now to save". So that is those bases covered(Hardware + Emulator + Mini) This however still leaves the welded and the people who can't afford a cart edition in the lurch. To which I take that sd2iec are somewhat ubiquitous these days particularly with the more casual user, 1541uII is for the hardcore user. But I feel that
1541IIu+ hundreds (probably has reach over a 1000 though)
sd2iec thousands
and then most 1541II users probably started with a sd2iec and then realized it didn't give them enough of what they want and then upgraded. So with this I might be able to make a "good enough" experience that uses the SD2IEC. If it was to be done on a 1541 physical disk you have the following cases..

Bit of game...
Please insert Disk 3 Side A
...seek
...load
Please insert Disk 2 Side B
...seek
...load
Bit more game...
Please insert Disk 1 Side A

If the game gets a 128 native version, then what would give me an extra "80K" over a C64 version, and given a 1571 doubled sided disk it would drop the disk flipping down to half, and I could load with burst.. but lots of work very little gain.

SD2IEC I can put all the files in a flat directory so I can just grab any file I want at any point, with a fast loader it shouldn't take too long, to fetch a bitmap portrait here, some dialog text there, battle animation here, level script there etc It will still pause and stutter a bit, but might be "livable"

If not the "can't afford a cart" people will be in the lurch and I could use the REU capabilities of the 1541UII and TC to make up for the lack of cart.
2019-02-21 07:03
oziphantom

Registered: Oct 2014
Posts: 478
Quoting cadaver
Claus_2015: thanks for the hint, eload is .. interesting :) Practically you setup loading first with the stock routines, then upload the short "drivecode" and resume with a fast protocol.

It's a 2bit timed protocol, so you can't have sprites and IRQs will be delayed while it waits for badline clearance, but screen can be on, so would be OK for typical games.


Typical games have sprites on the screen though. If I have sprites I could probably turn them off while loading, but I feel my game is unique in this aspect.

However eload does look interesting thanks for the link.
2019-02-21 08:40
Knight Rider

Registered: Mar 2005
Posts: 114
Please remember that the Sam's Journey fastloader is only supported by sd2iec v1.0.0. Some SD2IECs have an other firmware and can't be upgraded. Example SDRIVE1564 that has sd2iec v0.10.3 and cannot be upgraded.
2019-02-21 09:05
cadaver

Registered: Feb 2002
Posts: 1153
oziphantom: You can do a Y-range check and use the timed protocol only while outside the sprite area. Slower, but at least doesn't crash or force you to hide sprites.
2019-02-21 11:41
Krill

Registered: Apr 2002
Posts: 2804
Quoting oziphantom
and I could load with burst.. but lots of work very little gain.
When it comes to burst, indeed. I've recently added it to my loader, and it's not faster at all than a well-optimised bit-banging protocol.

But where do you get all the content to fill 5-6 disk sides? How much space do you reckon would everything take when well-compressed?
2019-02-21 11:48
Krill

Registered: Apr 2002
Posts: 2804
Quoting Knight Rider
Please remember that the Sam's Journey fastloader is only supported by sd2iec v1.0.0. Some SD2IECs have an other firmware and can't be upgraded. Example SDRIVE1564 that has sd2iec v0.10.3 and cannot be upgraded.
Really, those crappy non-upgradeable devices should go die in a fire. There's a limit to catering to emulators. Explicit SD2IEC support is already questionable, with it not being a drive replacement but a mass storage device.
2019-02-21 12:14
oziphantom

Registered: Oct 2014
Posts: 478
Quoting Krill
Quoting oziphantom
and I could load with burst.. but lots of work very little gain.
When it comes to burst, indeed. I've recently added it to my loader, and it's not faster at all than a well-optimised bit-banging protocol.

But where do you get all the content to fill 5-6 disk sides? How much space do you reckon would everything take when well-compressed?

I think Burst while not faster than 2bit in a tight coupled loop,if I'm pulling in a byte around other things, such as irqs, sprites, game logic, having 8 bits being transferred without a CPU having to be involved will make it a lot easier. As I can't miss the byte, and it will wait for me without needing to be sent again.
However does your code use Burst + 2Bit bang, because that would get you faster again right, as the Burst byte won't occupy CPU time while you transfer the 2bits and hence be almost for "free"?

the 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.
2019-02-22 09:39
cadaver

Registered: Feb 2002
Posts: 1153
One note after a shot at implementing eload: doing the setup for file load using IEC protocol will be murder for your interrupts, if you use Kernal (and it takes several frames.) However, as the device is known at this point, you could take a happycase approach, and implement your own simplified IEC send byte routine that can coexist with your interrupts. Also has the advantage that you can clobber whatever memory you like.
2019-02-22 10:38
Krill

Registered: Apr 2002
Posts: 2804
Quoting cadaver
One note after a shot at implementing eload: doing the setup for file load using IEC protocol will be murder for your interrupts, if you use Kernal (and it takes several frames.) However, as the device is known at this point, you could take a happycase approach, and implement your own simplified IEC send byte routine that can coexist with your interrupts. Also has the advantage that you can clobber whatever memory you like.
I did some research into that for Thundax's yet-to-be-released game which premiered at X 2018. He required an IRQ loader as well as an IRQ saver, both not resident in the drive, so also uploading the code using KERNAL had to be IRQ-friendly. I don't have the code here at the moment, and it needs some clean-up, but i'll post the gist of it soonish.
2019-02-22 13:33
Krill

Registered: Apr 2002
Posts: 2804
Quoting oziphantom
I think Burst while not faster than 2bit in a tight coupled loop,if I'm pulling in a byte around other things, such as irqs, sprites, game logic, having 8 bits being transferred without a CPU having to be involved will make it a lot easier. As I can't miss the byte, and it will wait for me without needing to be sent again.
However does your code use Burst + 2Bit bang, because that would get you faster again right, as the Burst byte won't occupy CPU time while you transfer the 2bits and hence be almost for "free"?
Burst is C-128 only (C-64 requires a relatively simple hardware mod), and burst and non-burst transfers are mutually exclusive, thus both cannot be employed at the same time. Burst uses the DATA line for data and only adds the SRQ line for clocking. The CLK line is required to signal "byte received" so the sender can clock out the next one. (There is still ATN, but it's only host->drive, and hardware ATN acknowledgement soiling the DATA line is a thing with burst as well, so let's not go into that.)

Now, burst-clocking out a bit requires 14 cycles at 2 MHz minimum (CIA timer period set to 6, two periods make up a bit cycle), anything faster yields errors due to the physical properties of the serial bus. That's 14 * 8 / 2 = 56 cycles at 1 MHz to transfer a byte. Add 6 cycles for the aforementioned CLK toggle, another 5 cycles to store the byte, and finally another 5 cycles for looping.

You're looking at 72 cycles minimum on C-64, which co-incidentally is exactly what the 2-bits+ATN protocol I use takes (it puts a new bit-pair every 18 cycles at 1 MHz on the bus). It also allows for interrupts, sprites and DMA without any restrictions.

So actually, the good old 2-bit asynchronous method (lda $dd00:lsr:lsr:eor $dd00 etc.) at 4*7 = 28 cycles for the raw byte would be the fastest one, after overhead it comes out at something like 64-ish cycles when allowing badlines, and 32-ish with screen off and no interrupts or DMA.

Bottom line: burst may make things "easier" to implement, but does not make for faster loading at all, interrupts, sprites and DMA or not.
2019-02-22 14:42
oziphantom

Registered: Oct 2014
Posts: 478
I forgot ATN was only one way.

If we step back from the leaf and inspect the tree though is there room to be gained?

So at the moment the code does this
grabs GCR bytes, decodes on the fly to "bytes" for block
once done
Sends block to C128
looks for and syncs next block
repeats until done
right?

So while the burst transfer is not faster than the 2 bits + ATN transfer, it does leave the 2mhz CPU free, giving you 112 clocks where the CPU could be doing other things. Like say reading and decoding a byte off the disk? At which point you probably don't need the fancy decode table to do it any more, giving you more drive RAM?
So a burst transfer looks like
find start block
read gcr
convert
start sending byte
read gcr
convert
start sending byte
..go until all bytes transferred
but to loosen the timings, you could detect if the machine is ready and send byte direct, or buffer the byte, and send one from buffer next time you check.

Also if c128 is in 1Mhz mode you have upto 56 clocks to "deflate" the byte on the host? And if I don't care just get it to me as fast as possible, 112 clocks to "deflate" in 2mhz mode.

So while the transfer it self is no faster, you don't have a read from disk, send data, read from disk, you can just pull bytes from the disk and sent immediately, and then you have a constant stream, baring sector and track movements?

Also the 1571 has a drive side auto-boot, that lets you load blocks into Drive RAM at disk insert, saving you from having to install the drive code from the host?

Or even switch to MFM and let the WD1770 chip do the bits -> byte conversion, giving you more CPU time to sync, buffer and send?
2019-02-22 15:15
Krill

Registered: Apr 2002
Posts: 2804
Some apt ideas there, will have to think about them thoroughly.

But a few remarks:
- On 1571, the decoding tables are in ROM, so already free in terms of RAM usage. They are somewhat sub-optimal and entirely different to what I came up with for 1541 (standing on lft's shoulders), but still, 100% on-the-fly reading + decoding + checksumming with 2 MHz.
- 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.)
- When going down that route, 50x-ish speed (around 20 KB/s) is possible without burst on C-64+1541.
- 1571 auto-boot is rather slow.
- I know close to nothing about WD1770.
2019-02-22 15:23
oziphantom

Registered: Oct 2014
Posts: 478
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.
2019-02-22 15:33
Krill

Registered: Apr 2002
Posts: 2804
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.
2019-02-22 16:38
oziphantom

Registered: Oct 2014
Posts: 478
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.
2019-02-22 16:40
Krill

Registered: Apr 2002
Posts: 2804
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.
2019-02-22 16:44
oziphantom

Registered: Oct 2014
Posts: 478
*= $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.
2019-02-23 08:52
ChristopherJam

Registered: Aug 2004
Posts: 1359
Quoting oziphantom
the 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?
2019-02-23 08:58
oziphantom

Registered: Oct 2014
Posts: 478
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.
2019-02-23 10:05
Krill

Registered: Apr 2002
Posts: 2804
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. :)
2019-02-23 12:25
oziphantom

Registered: Oct 2014
Posts: 478
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.
2019-02-23 13:39
ChristopherJam

Registered: Aug 2004
Posts: 1359
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.
2019-02-25 21:47
cadaver

Registered: Feb 2002
Posts: 1153
Hmm.. ended up making an NMI state machine to get the IEC stock protocol sends (before eload init, or for saving) reliable. The good part is that now that I got it running, can try to make it tidier.

According to the official protocol specs, it should be safe for the talker to spend whatever amount of time in each bit, after the initial ready-for-data handshake is done. However delaying the last bit apparently means JiffyDos activation (according to the SD2IEC firmware source), which isn't wanted in this case :)
2019-02-25 22:28
Krill

Registered: Apr 2002
Posts: 2804
Quoting Krill
I did some research into that for Thundax's yet-to-be-released game which premiered at X 2018. He required an IRQ loader as well as an IRQ saver, both not resident in the drive, so also uploading the code using KERNAL had to be IRQ-friendly. I don't have the code here at the moment, and it needs some clean-up, but i'll post the gist of it soonish.
Quoting cadaver
Hmm.. ended up making an NMI state machine to get the IEC stock protocol sends (before eload init, or for saving) reliable. The good part is that now that I got it running, can try to make it tidier.
Okay, didn't get around cleaning it up yet and not sure if this helps, but this is an example of what i did:
         ; scratch "TEMP"
         lda #FLOPPYMW - scratch
         ldx #<scratch
         ldy #>scratch
         jsr $ffbd; SETNAM
         lda #$6f; secondary address: command/error channel
         sta $b9
         lda #$20; LISTEN
         jsr sendslow
         jsr $f3e6; send secondary address and filename
         lda #$3f; UNLISTEN
         jsr sendslow
         jsr $ee03; clear ATN

         [...]

sendslow ora $ba
         sta $95
         lda $dd00
         and #%11001111
         ora #%00001000
         sta $dd00
-        bit $dd00
         bpl -
         sei
         jmp $ed5a; send byte
The problem with the KERNAL calls is that sending LISTEN, UNLISTEN or TALK can block for a long time after SEI if the drive happens to be busy. The code above works around that by partially re-implementing the LISTEN and UNLISTEN calls. Once those return, the drive will respond quickly enough to regular KERNAL bus access, making for only moderate IRQ stalling. :)

What does the NMI state machine do? :)
2019-02-25 23:01
cadaver

Registered: Feb 2002
Posts: 1153
Cool, thanks!

The NMI code that I wrote basically reimplements the IEC protocol send of a single byte, with or without EOI. ATN has been set by main program beforehand. The timing is not terribly picky, I'm running now from a timer that is about one and half rasterlines.

The eload init is potentially worse than just a fastloader upload, because it's searching for a file from the memory card.
2019-02-26 00:56
Mr.Ammo
Account closed

Registered: Oct 2002
Posts: 228
Quoting oziphantom
[..] To which I take that sd2iec are somewhat ubiquitous these days particularly with the more casual user, 1541uII is for the hardcore user. But I feel that 1541IIu+ hundreds (probably has reach over a 1000 though) sd2iec thousands [...]

I believe your numbers for the 1541U2 and U2+ are off. Gideon mentioned numbers during his ZOO party (October 2017) talk (https://scenesat.com/videoarchive/47?t=74665):
status October 2017
-----------------------
1541Ultimate        750
1541Ultiamte-II   3.400
Ultimate-II +     1.300

The Ultimate 64 (U2+ included) already passed the 1001 units mark some time ago while the U2+ is also still being sold steadily.
2019-02-26 07:55
oziphantom

Registered: Oct 2014
Posts: 478
I was going for magnitude rather than hard numbers. But thank you for the hard numbers, they are higher than I was expecting, from the low batches and long waiting lists I assumed Gideon hadn't even made that many ;) Its puts 1541U comparability at mid thousands, the catch being that most posts I see are
"I just got SD2IEC but I want to run X"
"SD2IEC suxors and can't run it you need 1541UII"
"Oh ok, I will look at those"
"Damn those are expensive"
"Yeah but worth it"

So while 5000 people might have 1541UII, 4100 of them probably have an SD2IEC as well ;)

Does it support REU and booting in 128 mode now while connected, or is it still detached mode for 128?
2019-02-26 08:04
Krill

Registered: Apr 2002
Posts: 2804
It's time for Pi1541 to pick up steam and replace SD2IEC.

Sadly, most people won't build one themselves, and i only see overpriced offers of ready-made funny-looking boxes.
2019-02-26 08:36
oziphantom

Registered: Oct 2014
Posts: 478
I'm waiting for the Rev C board before I dive in. Sadly it doesn't currently support eLoad, but by the time my game comes out it might.
To be fair a lot of SD2IEC are expensive because they have a "nice case", I think it is what the market wants and a key way for people to differentiate their product from the hundred other identical ones.

I also want to see if I can get the Pi to overlay on the RGBI screen.
2019-02-26 09:33
Krill

Registered: Apr 2002
Posts: 2804
SD2IEC complete with 1541-like plastic case goes for about €50 at the time of writing this, Pi1541 hat with 1541-like plastic case for €70, complete package with a RasPi for €150.
2019-02-26 10:57
Oswald

Registered: Apr 2002
Posts: 5007
gideon should make a cost reduced 1541u, he would sell zillions of it.
2019-02-26 11:05
Krill

Registered: Apr 2002
Posts: 2804
I think a fast-enough microprocessor-based solution able to 100% emulate the drive is the better approach compared to FPGA. Cheaper, too. :)

(Not to mention more maintainable/hackable with more people being able to code software rather than hardware logic.)
2019-02-26 11:13
oziphantom

Registered: Oct 2014
Posts: 478
uDrive might launch this century... maybe...
2019-02-26 11:40
Krill

Registered: Apr 2002
Posts: 2804
Good joke! :)
2019-02-26 12:57
chatGPZ

Registered: Dec 2001
Posts: 11088
Quote:
gideon should make a cost reduced 1541u

it is already reduced to the max. if this would be a regular product (without a person behind it that is basically working for free) it'd certainly cost considerably more.
2019-02-26 14:47
Oswald

Registered: Apr 2002
Posts: 5007
Quote: Quote:
gideon should make a cost reduced 1541u

it is already reduced to the max. if this would be a regular product (without a person behind it that is basically working for free) it'd certainly cost considerably more.


I mean, many users are not sceners, and they only need the 1541 functionality. They's pay more for something better than sd2iec, but 1541u is too much for them.
2019-02-26 14:51
chatGPZ

Registered: Dec 2001
Posts: 11088
sure, but you dont really win anything by removing the cartridge/reu stuff. perhaps 10 euro if you kill the IEC connector and some USB. and then you end up with two different products which each sell less than before - driving up the costs again. not worth the trouble.

edit: forgot that unlike with chameleon, the IEC is still required for basic functionality :)
2019-02-26 16:03
oziphantom

Registered: Oct 2014
Posts: 478
I think they mean

if you ditch the reu, cart port, dma injection menus, tape port all the other func stuff, now you don't need a FPGA anymore, and make a all new thing that is just some fast enough microcontroller that does "the thing", which would be a solid saving over the 1541UII.. however I do feel this is looking at it the wrong way..

lets not cut down the 1541U11 lets improve the SD2IEC, i.e boost its cpu such that it can do a 1541 drive. This would increase the price a bit of the SD2IEC but makes it a lot more useful.
2019-02-26 16:31
Krill

Registered: Apr 2002
Posts: 2804
Pretty sure current CPUs for the task are no more expensive than the original SD2IEC's CPU at its original release.
2019-02-26 19:22
chatGPZ

Registered: Dec 2001
Posts: 11088
at this point just use pi1541 :)
2019-02-26 19:57
hedning

Registered: Mar 2009
Posts: 4550
Quote: at this point just use pi1541 :)

+1

The pi1541 is a lot better, cheaper and more accurate than anything you could do to boost the sd2iec. We should not adapt stuff to the sd2iec.
2019-02-26 21:34
Mr.Ammo
Account closed

Registered: Oct 2002
Posts: 228
Quoting oziphantom
[...] I assumed [...]

Do not to assume.
Listen to Krill.
2019-02-27 00:48
cadaver

Registered: Feb 2002
Posts: 1153
Don't see harm in adapting stuff as long as it does detection properly and continues to run on proper drives.

Have to take care when testing, for example I just found out that SD2IEC doesn't give a shit whether you send the EOI signal for filenames or commands, as long as you Unlisten afterward. A real 1541 does :)
2019-02-27 06:56
hedning

Registered: Mar 2009
Posts: 4550
Quote: Don't see harm in adapting stuff as long as it does detection properly and continues to run on proper drives.

Have to take care when testing, for example I just found out that SD2IEC doesn't give a shit whether you send the EOI signal for filenames or commands, as long as you Unlisten afterward. A real 1541 does :)


That is the way to go if you want to support it, of course. But sd2iec-only adaptations would be devastating and sad.
2019-02-27 08:19
oziphantom

Registered: Oct 2014
Posts: 478
well the trick is an sd2iec "might" just be able to pull it off good enough to not be a massive pain. Where a physical disk won't be able to. However a 1581 might be able to, it will still be a lot slower but its disk capacity is high enough. A 1581 on a 128 is probably in the realms of livable. However supporting a 1581 on a 128 is probably worse than supporting a sd2iec ;)
2019-02-27 09:07
soci

Registered: Sep 2003
Posts: 472
Would it be difficult to have a KERNAL fallback without nuking the vector tables? Making the loader serial bus specific does not help when trying to run stuff from an IDE64.
2019-02-27 10:49
cadaver

Registered: Feb 2002
Posts: 1153
Eload easily needs the most code due to the init needed for each file. That or any sector buffer could go over the OS-sensitive areas.

It's kind of a lot work to support everything, but when you don't leave anything up to 3rd party later fixes, the initial user reception should be better.

(if your game is huge, I can understand not having 1541 drivecode, and the extra work for disk swap screens)
2019-02-27 10:53
oziphantom

Registered: Oct 2014
Posts: 478
Its hard to say until the game is done. Or even started, I'm just at the planing and early test stage. I guess an IDE64 with CF is going to be "as" fast but as just KERNAL and not fastloader, will it be fast enough? It connects to the expansion port right? Does it have any fancy DMA injection methods, or can it map file data into DEXX/DFXX GEORAM style? Remember this is being compared to an instant bank of a cartridge.

Again this is something the 128 would make trivial, as I could just switch to bank 1,move the ZP elsewhere and then I can just keep the ZP and lower variables untouched. Switch back when you want to do loading, then return back to lower RAM being bank 1. Does IDE64 support 128 native?
2019-02-27 11:02
cadaver

Registered: Feb 2002
Posts: 1153
You can test IDE64 in VICE. It works almost like "true drive emu" off, ie. CHRIN is fast, and IRQs get delayed only about a line, if at all.

There are also the IDE64-specific block read/write calls, see http://www.ide64.org/guide.html
2019-02-27 12:20
Krill

Registered: Apr 2002
Posts: 2804
Quoting cadaver
You can test IDE64 in VICE. It works almost like "true drive emu" off, ie. CHRIN is fast, and IRQs get delayed only about a line, if at all.l
Indeed, using my loader's KERNAL fallback with IDE64 didn't show any glitches with the border-opening test application last time i checked. Of course, same for 1581, but that's supported natively. :)
2019-02-27 21:27
cadaver

Registered: Feb 2002
Posts: 1153
Working eload-based game fastloader here: https://github.com/cadaver/c64gameframework

It's tangled quite deep with the rest of the framework (in loader.s), so may not be very usable outside of it.
2019-02-28 00:50
soci

Registered: Sep 2003
Posts: 472
> Its hard to say until the game is done. Or even started, I'm just at the
> planing and early test stage. I guess an IDE64 with CF is going to be "as" fast
> but as just KERNAL and not fastloader, will it be fast enough?

Depends. Some benchmarks:
https://singularcrew.hu/idedos/perf.php

> It connects to the expansion port right?
> Does it have any fancy DMA injection methods, or can it map file data into
> DEXX/DFXX GEORAM style? Remember this is being compared to an instant bank of
> a cartridge.

No, it's not instant, does not do any DMA and it also does not directly map in
storage like rom, flash or ram cartridges.

Data is accessed using KERNAL calls and the operating system moves data around
or provides byte-by-byte access to files. If it's a CF card, hard disk, or some
sort of network drive it does not matter.

> Again this is something the 128 would make trivial, as I could just switch to
> bank 1,move the ZP elsewhere and then I can just keep the ZP and lower
> variables untouched. Switch back when you want to do loading, then return back
> to lower RAM being bank 1. Does IDE64 support 128 native?

The hardware kicks it into C64 mode before it even starts, so no.

> There are also the IDE64-specific block read/write calls, see
> http://www.ide64.org/guide.html

That's a bit old. For example if you handle directory paths like this that's
IDE64 specific. Instead paths should be written using the CMD syntax so that
there's some compatibility with CMD devices.

Up to date information is in the user's guide. Section 13 describes KERNAL
calls and memory use:

https://singularcrew.hu/idedos/beta/IDE64_users_guide_beta.pdf

The operating system was written so that it only "trashes" memory locations
which would be trashed the same way on a stock machine as well when accessing a
serial device. The addresses are listed so there's no need to guess what to
back up.
2019-02-28 05:22
Krill

Registered: Apr 2002
Posts: 2804
Quoting Krill
not sure if this helps, but this is an example of what i did
Quoting cadaver
Working eload-based game fastloader here: https://github.com/cadaver/c64gameframework
Nice to see that my suggestion helped. :)
2019-02-28 05:33
oziphantom

Registered: Oct 2014
Posts: 478
Quoting cadaver
Working eload-based game fastloader here: https://github.com/cadaver/c64gameframework

It's tangled quite deep with the rest of the framework (in loader.s), so may not be very usable outside of it.


Very helpful, thank you.
2019-02-28 06:02
oziphantom

Registered: Oct 2014
Posts: 478
Quoting soci
> Its hard to say until the game is done. Or even started, I'm just at the
> planing and early test stage. I guess an IDE64 with CF is going to be "as" fast
> but as just KERNAL and not fastloader, will it be fast enough?

Depends. Some benchmarks:
https://singularcrew.hu/idedos/perf.php

That is pretty fast ;)


Quoting soci
Up to date information is in the user's guide. Section 13 describes KERNAL
calls and memory use:

https://singularcrew.hu/idedos/beta/IDE64_users_guide_beta.pdf

The operating system was written so that it only "trashes" memory locations
which would be trashed the same way on a stock machine as well when accessing a
serial device. The addresses are listed so there's no need to guess what to
back up.

the quality Soci levels of documentation I see.. no if only Tass would let you "pin" addresses and let the rest flow around them ;)
2019-02-28 06:06
oziphantom

Registered: Oct 2014
Posts: 478
I've come up with a better way to support the 1541IIU/EF3/TC the way you support the mini is by making a Ocean 512K cart as they are binary compatible. You just rip out the EEPROM saving and tell them to "press menu and take a snapshot now". While the aforementioned devices do have freezers, on hardware it is "risky". However saving is user instantiated in an end of the level menu, to which if it takes longer to save/load "meh", so it can just use a "save disk", be it a physical disk or an emulated one, using pure KERNAL routines.
2019-02-28 10:52
chatGPZ

Registered: Dec 2001
Posts: 11088
for TC64 and 1541U (and EF of course) just make a regular EF cartridge (WITH saving to flash - remember to use the EAPI however). Both let you save the updated cartridge. regular "freezing" on the other hand will NOT work with an ocean cartridge on either device.
2019-03-02 14:51
cadaver

Registered: Feb 2002
Posts: 1153
Slight update to the SD2IEC fastloader code I wrote, now there's a generic IEC send reimplementation without any long IRQ pauses. Can also be used outside SD2IEC for fastloader uploading.

There is a short IRQ disable, but it's only to prevent SD2IEC enabling JiffyDOS mode on the last bit of ATN bytes.

Initially I thought SD2IEC is more lax regarding EOI, but it turns out to be the same. The bit send timing itself must be slower on the C64 side when communicating with a real drive.

https://github.com/cadaver/c64gameframework/commit/3397dbc24d01..
2020-02-26 10:50
Krill

Registered: Apr 2002
Posts: 2804
Quoting Krill
Okay, didn't get around cleaning it up yet and not sure if this helps, but this is an example of what i did:
         ; scratch "TEMP"
         lda #FLOPPYMW - scratch
         ldx #<scratch
         ldy #>scratch
         jsr $ffbd; SETNAM
         lda #$6f; secondary address: command/error channel
         sta $b9
         lda #$20; LISTEN
         jsr sendslow
         jsr $f3e6; send secondary address and filename
         lda #$3f; UNLISTEN
         jsr sendslow
         jsr $ee03; clear ATN

         [...]

sendslow ora $ba
         sta $95
         lda $dd00
         and #%11001111
         ora #%00001000
         sta $dd00
-        bit $dd00
         bpl -
         sei
         jmp $ed5a; send byte
Meanwhile, it turned out that i forgot the EOI delay (http://unusedino.de/ec64/technical/aay/c64/romeeb3.htm), and it's quite crucial. So "sendslow" becomes:
sendslow ora $ba
         sta $95
         lda $dd00
         and #%11001111
         ora #%00001000
         sta $dd00
-        bit $dd00
         bpl -
         ldx #$b8
-        dex
         bne -
         sei
         jmp $ed5a; send byte
DFLTO ($9a) for LISTEN and DFLTN ($99) for TALK also don't appear to be set, which i do in a clean version in another codebase:
            CLEAR_DATA_OUT_CLEAR_CLK_OUT_ASSERT_ATN
:           SET_FLAGS_N_DATA_V_CLK
            bpl :-
            ldx #$b8; delay
:           dex     ; of
            bne :-  ; ~1 ms
            lda FA
            sta DFLTO
            ora #SA_LISTEN
            sta BSOUR
            sei
            jsr NOEOI; send byte
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
csabanw
Dr. Doom/RAD
Dymo/G★P
Guests online: 317
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Fullscreen Graphicians
1 Carrion  (9.8)
2 Joe  (9.8)
3 Duce  (9.8)
4 Mirage  (9.7)
5 Facet  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.153 sec.