| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
2 bit irq loader
Hmm, just a question...
Is there a 2 bit irq loader, which doesn't require blocking other interrupts while loading a byte?
i.o.w. Is there a realy fast irq loader which doesn't block any interrupts and let me use my beloved sprites? :-)
|
|
| |
6R6
Registered: Feb 2002
Posts: 245 |
Krill's 2bit atn loaders:
Fixup #$00
Doc Bacardi's Dreamload (also 2 bit atn):
http://members.surfeu.de/docbacardi/dload/index.html
should do nicely..
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Those are ofcourse not as fast as a non-irqloader. |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Ok...
But, does anyone has expirience with the usage of these loaders? I don't mean the implementation, but more the workings. Because you can't have more than one drive connected, does this give a lot of users problems?
b.t.w: I always thought that to setup atn, would also require specific timing... and therefor didn't work too well with sprites/badlines |
| |
hollowman
Registered: Dec 2001
Posts: 474 |
the user problems i've experienced are usually more about "loader x doesnt work on my drive y" |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@MRT: ATN is simply yet another line which the C64 can control. So, with 2bit+atn you simply let ATN become your clock reference and uses DATA+CLK as pure data lines instead. This way you can asyncronously (no problems with timing since ATN is the clock) send 2bits at a time.
If you instead do synchronous transfer, i.e. when timing IS a problem, then I guess you in theory could use all three lines as data lines and thus send three bits per write, however that feels a bit messy. This however only works from C64->Drive since it's only the C64 who can drive the ATN line.
Another way is to do semi-synchronous transfer. First you synchronize for instance per byte using ATN, then you synchronically burst 8 bits using DATA+CLK, i.e. 2 bits at a time.
Blah blah blah crap talk crap talk... :D |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
What's the fastest IRQ loader, which just have to work for a standard PAL C64 + 1541? |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Don't know the answer, but there should be no reason that a PAL-only loader would be faster than one which can adjust the C64 side code to work with both PAL & NTSC (since the drive runs at same speed anyway) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
The speed largely depends on how fast the drive code can decode GCR data, how it handles interleave, and what the C64 loader does while waiting. Krill has an interleave-less loader (i.e. it reads the next sector out of order, and assembles on the C64 side) that also decrunches while waiting for the drive to read and decode the next sector. I had an idea earlier for a custom GCR format that should virtually eliminate decoding time that I think he's going to incorporate. So if you want something really fast, check with Krill...
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
The question about the fastest loader is a bit like the one about the best cruncher or assembler. It depends heavily on your needs and requirements. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Also.. Fastest loader + tightest data compressor=quicker loading |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quote: The question about the fastest loader is a bit like the one about the best cruncher or assembler. It depends heavily on your needs and requirements.
Ok, how about...
- It has to work with a C64 + a 1541, and doesn't have to work on other drives.
- It loads 16 blocks ($1000) of code, which can't really be compressed much, so let's say it's not compressed.
- One IRQ each frame for playing music, and doing simple stuff like switching some text. The IRQ will use up to 48 ($30) rasterlines.
- No need for cycle excact timing. Actually the IRQ could vary several rasterlines if that would make the loader faster.
- No sprites on the screen.
Wonder if it would be possible to use all 3 bits for data transfer for a loader with these kinda requirements. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@Cruzer: Only the C64 can control the ATN line so you can't make use of all three bits as data bits when sending from 1541->C64 (loading). Saving could in theory ofcourse make use of it. :D World's fastest hiscore saver anyone? :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
what about programming ATN as output, but still using it as input? works with certain other i/o lines atleast :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
I don't think that would work. If you check with the 1541's bus circuitry, the ATN line is heavily interlocked with the data line, and there is some blocking diode in the 1541->C64 direction, iirc. I second JackAsser there, C64->1541 works, but not the other way around. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
ah yes, i remember now :) |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Ehr... silly question maybe. But I'm writing my own loader now and I was wondering why the VIA reg and the CIA reg both have input and output bits.
Wouldn't it be more logical if you would just have a data bit and a clock bit, which would reflect the current state?
What is the benefit of having the in/out bits per line?
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
The benefit is that you don't need to switch the data direction all the time. |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Hmm, but do you need to clear it?
ie. when I set the data-out from low to high, will the data-in automatically be high too?
Or will the data-in remain the same until the other party lowers it?
And if so, can I reset it too? by clearing the via1 for example?
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
CLK/DATA IN is active when the output is active on either the computer or one of the drives. If all are inactive, CLK/DATA IN is inactive.
|
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
ehr... yeah, but on the VIA1 register... When I set data-out to active, will then automatically the data-in on that same VIA1 register be set to active?
Edit: Or will the data-in on that VIA1 register only be set to active, when the C64 (or another drive) sets that line to active? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Why don't you just check it yourself? Doesn't take long to code, really. :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Oh, and btw., i have an idea on how to make the 2bit+atn protocol work with multiple drives connected (and turned on). Will implement that some day.. |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Sending "m-e" 0502 784c0602 to all other drives?
("m-e" 0402 is even shorter :) |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Quote: Why don't you just check it yourself? Doesn't take long to code, really. :)
Dunno, I'm trying to code something for a drive for the first time. So I don't have any experience with this.
also, Vice lacks a way to "debug" the drive. I'd like a drive monitor as well :) |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Have you tried "dev 8:" in VICE monitor? |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
wooooottt....
If this does what I hope it does... :-DD
C0oOo0lio0OQ |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote: Sending "m-e" 0502 784c0602 to all other drives?
("m-e" 0402 is even shorter :)
Obviously you haven't tried that code or muting other drives when using 2bit+atn protocols before posting this :) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Quote: Oh, and btw., i have an idea on how to make the 2bit+atn protocol work with multiple drives connected (and turned on). Will implement that some day..
Just out of interest, does this involve programming the idle drives to execute some kind of loop or is it something more convenient?
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
It's a loop, but i will try making the loader work on all connected drives, i.e., installing it on any drive on the bus and let the user load from any drive, i.e., the loader tries finding the files on any inserted disk. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
krill, I think this is an overkill, also what happens if the c64 resets while the demo is running ? he will find himself with most of his drives in an infinite loop. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
No, i have already implemented a watchdog routine (using a timer irq) in the drive code, so any loop waiting for the c64 will be terminated and the drive reset if it just takes too long.
And it might be overkill for a demo, but i will make this loader more and more a loader suitable for games, as well. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Oh, and i also got rid of this stupid 2 first chars filename matching, now you can load files using their full names (1-16 chars) while still using the dir buffer, so it does still not need to be read and parsed on every load. A 16-bit hash value matching does the trick here. :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
nice:) |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Can you still use the 2Mhz-mode on faster drives then? When we tried a similar idea back then, we couldn't figure how to make a fast enough loop-routine for the good old 1541 :( |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Oh, haven't tried that yet, but i can always clock down the drive-side sending routines to 1 mhz which should not matter much since the c64 is clocked at 1 mhz anyways. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Our experiments showed that it does help significantly if the drive runs at 2Mhz and can f.e. react faster to the handshaking. For the benefit of that, we let down the multiple-drive-thingie. Well, after all, it's a choice of design :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Yes it is. But since the 1541 is the least common denominator, all other drive types don't really have to be faster, at least for demos. And i'd always prefer more compatibility over more speed. :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
And if in doubt, you can still make it optional. :) |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Quote: Why don't you just check it yourself? Doesn't take long to code, really. :)
Ok, well I've coded something myself but it doesn't clear-up things. :-D
check out the code snipplets:
drive-code ;set lines to low
lda $1800
and #%11110000
sta $1800
;wait for both lines high
lda #%00000101
and $1800
cmp #%00000101
bne *-7
c64 code ;wait for both lines low
lda #%11000000
bit $dd00
bne *-3
;set both lines high
lda $dd00
and #%00001111
ora #%00110000
sta $dd00
The drive-code should set both lines (clock+data) to low and then wait for lines to go high.
The C64 code should wait for the lines to go low, and then set the lines high.
In both the drive and the c64 the interrupts are disabled by the sei command.
Now what happens is... nothing :-D
The drive sets the lines to low and waits until the lines go high again.
The C64 keeps waiting for the lines to go low.
And when I look at VIA1 ($1800) in the drive, I see that the drive actually set the lines to low, but the CIA2 register ($dd00) in the C64 still shows the lines as high. :-S
Any of you drive gurus got any idea on what I'm doing wrong?
|
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
K, I've got a message from Dahl, telling me that the bits get inverted. So I checked a little, and found the following table...
|DC|DC|DC|DC|
-----+--+--+--+--+
$1800|11|01|10|00|
-----+--+--+--+--+
$dd00|00|01|10|00|
-----+--+--+--+--+
In other words, only when setting both lines to low or high, they get inverted. But when one sets only 1 line high or low, the lines won't get inverted.
Is this correct? |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: K, I've got a message from Dahl, telling me that the bits get inverted. So I checked a little, and found the following table...
|DC|DC|DC|DC|
-----+--+--+--+--+
$1800|11|01|10|00|
-----+--+--+--+--+
$dd00|00|01|10|00|
-----+--+--+--+--+
In other words, only when setting both lines to low or high, they get inverted. But when one sets only 1 line high or low, the lines won't get inverted.
Is this correct?
No. They are always inverted. Have you setup $dd02 correctly?
Also, you can use BIT $1800 when waiting, for less jitter.
|
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Hmm, didn't set the data direction registers coz I thought the default setting should be good. The both out-lines are enabled on both sides by default. But, I forgot to check if they were still correct when I made the table above... :-S
I'll check it again. :-)
bout that bit $1800...
You cannot use it when you want to check if both lines are high, can you? Then you check if at least one of the two lines (or both) is high.
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
@MRT - are you sure you didn't get clock and data the wrong way around on either your reads or your writes? That would explain the seeming lack of inversion when they are different to each other :)
err, but not the 00. I'll go get some coffee now :-P |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
MRT: The bit instruction is to and what cmp is to sbc, more or less. It does mainly the same, just that your registers aren't altered, instead only the flags. So if the Z-flag is set after the bit instruction, both lines are low, if not, directly branch to the bit opcode again.
And that table seems b0rked. :)
Oh, and i just made a new version of my loader, still interesed, MRT? |
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
@ChristopherJam:
poor me some too ;-)
@Krill:
He he, I know how bit works :)
Just saying you can use it only to check if all is low or all is not low.
And hell yeah... I'm interrested!
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Quote: Yes it is. But since the 1541 is the least common denominator, all other drive types don't really have to be faster, at least for demos. And i'd always prefer more compatibility over more speed. :)
Really? Now, that's good news >:-> |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: @ChristopherJam:
poor me some too ;-)
@Krill:
He he, I know how bit works :)
Just saying you can use it only to check if all is low or all is not low.
And hell yeah... I'm interrested!
@MRT: BIT conviniently copies bit 6 and 7 to the N and V flags. Hence:
lda #$c0
bit $dd00
beq data_and_clock_low
bvc data_low
bvs data_hi
bmi clock_low
bpl clock_hi
I might have mixed up data and clock ofcourse...
|
| |
MRT
Account closed
Registered: Sep 2005
Posts: 149 |
Quote: @MRT: BIT conviniently copies bit 6 and 7 to the N and V flags. Hence:
lda #$c0
bit $dd00
beq data_and_clock_low
bvc data_low
bvs data_hi
bmi clock_low
bpl clock_hi
I might have mixed up data and clock ofcourse...
I understand the bit opcode, but when scanning for both bit set, I don't think your code is cheaper then the code below? ;wait for both lines high
lda #%11000000
and $dd00
cmp #%11000000
bne *-7
When both bits are set I use 10 cc. When both bits are set in your example it would also take 10 cc, when I take the shortest path (see code below) ;wait for both lines high
lda #%11000000
bit $dd00
bvc *-3
bmi *-5
The difference here is thet your code is faster when both bits aren't set. But... You can only do this for $dd00 and not for $1800, and your code will have a different timing for each different pair of bits.
I'm writing a loader which is partly time-based, so I need to have stable timing. |
| |
j0x
Registered: Mar 2004
Posts: 215 |
MRT: It's not necessary to load the accumulator when only using the N and V flags
How about this one (assuming you want to do what your first code snippet does, not the second):
lda #$bf
cmp $dd00
bcs *-3
? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
MRT: how stable? Bit+branch still gives you at least 7 cycles jitter. For less jitter, you need to apply a technique known from stable rasters, called half variance. But you only need that if you don't handshake/sync for many many cycles. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
BIT has an implicit AND that sets the Z reg. To wait for DATA use BMI/BPL. To wait for CLOCK use BVC/BVS. To wait for both, use lda #$c0 and BEQ/BNE.
On the 1541 you lda #1, #4, or #5 and then BEQ/BNE.
|
| |
j0x
Registered: Mar 2004
Posts: 215 |
Magervalp: I think MRT questions using BIT for checking that *both* bits are 1. lda #$c0 bit $dd00 will set the zero flag if and only if both bits are zero. If one bit is 1 and the other is 0, then the BNE will branch, which is not (if I understand MRT correctly) the desired behaviour. But you're right: checking that both bits are 0 can be achieved by checking the zero flag.
/Stefan
|
