| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Detect C128 in C64-mode without exploiting 2mhz mode?
Reason: Easyflash emulation in 1541u2 doesn’t work in 2mhz mode. |
|
| |
Count Zero
Registered: Jan 2003
Posts: 1933 |
No sure about $01 but instead of $37 it always reports $77 on a c128 in c64 mode after powerup. Thing is that other hardware may influence a stock c64 the same way I suppose.
http://unusedino.de/ec64/technical/aay/c64/zp01.htm
Bit 6 description is not clear here. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: No sure about $01 but instead of $37 it always reports $77 on a c128 in c64 mode after powerup. Thing is that other hardware may influence a stock c64 the same way I suppose.
http://unusedino.de/ec64/technical/aay/c64/zp01.htm
Bit 6 description is not clear here.
Ahh very interesting!
Indeed the MOS8502 have P0-P6 defined whereas MOS6510 only have P0-P5.
Digging schematics now. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
P6 is caps-lock. Since it's generally advised to have caps-lock unpressed during boot P6 will always be 1. Specifically it can never be 1 on a MOS6510.
So if it's P6=1 it's definitely a C128. If P6=0 it still can be a C128. |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Define "exploiting 2 MHz mode". =)
Is it okay to read $D030 after reset?
Should be $FD (turbo mode off, line-skip off).
(Beware for Turbo Chameleon: it has $FE for turbo mode off but $FF for turbo mode on, which is the same value a C-64 reads there.)
Either way, only C-128 can have bit 1 (line-skip) set to 0. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
all port bits are there and they also work - see https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/CPU.. ... i dont think they can be used to detect c128 reliably
BUT... whats the problem with 2MHz? just put a small code snippet to RAM, bank out the EF, do what you need to do and switch back? if that still makes U2 freak out.... wtf, its broken. |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quote: Define "exploiting 2 MHz mode". =)
Is it okay to read $D030 after reset?
Should be $FD (turbo mode off, line-skip off).
(Beware for Turbo Chameleon: it has $FE for turbo mode off but $FF for turbo mode on, which is the same value a C-64 reads there.)
Either way, only C-128 can have bit 1 (line-skip) set to 0.
Whoops. Should be:
Is it okay to read $D030 after reset?
Should be $FC (turbo mode off, line-skip off). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
better: if its $ff, then its a c64 |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting Groepazbetter: if its $ff, then its a c64 Or a Turbo Chameleon in turbo mode, no? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: all port bits are there and they also work - see https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/CPU.. ... i dont think they can be used to detect c128 reliably
BUT... whats the problem with 2MHz? just put a small code snippet to RAM, bank out the EF, do what you need to do and switch back? if that still makes U2 freak out.... wtf, its broken.
Never even considered that! Stupid me! :D |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Whoops. Should be:
Is it okay to read $D030 after reset?
Should be $FC (turbo mode off, line-skip off).
Yes, that's a good solution also! |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Define "exploiting 2 MHz mode". =)
Is it okay to read $D030 after reset?
Should be $FD (turbo mode off, line-skip off).
(Beware for Turbo Chameleon: it has $FE for turbo mode off but $FF for turbo mode on, which is the same value a C-64 reads there.)
Either way, only C-128 can have bit 1 (line-skip) set to 0.
By exploiting 2Mhz mode I mean enable 2Mhz mode and measure something compared to say raster or CIA timer etc.
ROM code can't run safely in 2Mhz using a 1541u2. But as Groepaz said, why don't I run that code in RAM? I really feel stupid now. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
Quote:Or a Turbo Chameleon in turbo mode, no?
depends :) when d030 bit is emulated, then not =P |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
just use the VDC. Read D600, you will get something in the form of
%slv0000c
where s is the status bit which may be 0 or 1 depending if the VDC is ready. So you could write an address to D600, then read D600 and wait for bit 7 to become 1 if it doesn't within a few hundred clocks, not a VDC.
l is the light pen, should be 0 but it can be triggered the same way a VIC one can be so not 100% safe. Or even set up the "trigger light pen" state and make sure it happens?
V is vblank, so you can expect it to be 0 for most of a frame, then 1 for quite a while.
c will be 0 or 1 depending on the VDC version the 128 has and is thus stable.
checking for VBlank should be a pretty solid check, using the wait for ready will fail on VICE as the VDC is "always" ready on x128.
a C64 will hit D400 for the reads, which is open bus.
also D500&D700 are open bus on a C128. Is there a setup for the SID to output something on it readable registers that are "stable" across cycles? I.e does the random number change every cycle? or you can set up the envelope to be a long pulse. then
lda D41C
cmp D51C
on a C64 they will match, on a C128 they won't.
Has anybody done a solid investigation of the Z80 boot ROM. It must modify some RAM values which might survive the 6502 boot sequence, which one could snoop for. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
Quote:a C64 will hit D400 for the reads, which is open bus.
this is kinda unreliable, you can read back what was written to SID for a surprisingly long time |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
does it just store 1 or does it store multiple 'values'
say could you
write D600
write D601 <- trash values stored in SID??
read D600
or since the VDC mirrors all the way through
lda D600
write other value to D601
lda D602 <- should give you D600 value, not what you wrote to D601? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
as said, its not reliable, you usually get the last value written to the register - but it may or may not be different, randomly. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
I use this in superfluid: ldx #$fe
cpx $d030 ; C=1 if C128Getting the state into carry allows it to be rol:ed into acc or a zp loc. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I use this in superfluid: ldx #$fe
cpx $d030 ; C=1 if C128Getting the state into carry allows it to be rol:ed into acc or a zp loc.
Brilliant, thanks |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
now the question is... how does any of this help with "Easyflash emulation in 1541u2 doesn’t work in 2mhz mode." ? =) wouldnt you have to detect 1541u2 instead? =) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: now the question is... how does any of this help with "Easyflash emulation in 1541u2 doesn’t work in 2mhz mode." ? =) wouldnt you have to detect 1541u2 instead? =)
That’s the follow up question! |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: That’s the follow up question!
First I want to detect c128 in a safe way and offer 2mhz mode and then add a disclaimer for 1541u2 user or detect it and disable the feature |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
Why not just offer it as an option (default disabled)? Autodetection is doomed to fail in one way or another :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Why not just offer it as an option (default disabled)? Autodetection is doomed to fail in one way or another :)
It is an option already.. yeah. Maybe add a disclaimer |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Currently making the automap to show on the VDC always. It would be very nice not to have to enable it explicitally. Any options? I don’t wanna mess with the VDC regs unless I’m sure it’s really there. Can you reliably detect the presence of a VDC-chip? I know several possible solutions but is also afraid of GP’s ”doomed to fail”. Is detecting a VDC chip really doomed to fail? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
FWIW, currently doing:
ldx #0
ldy #5
stx VDCADR
:
bit VDCADR
bmi vdcFound
inx
bne :-
dey
bpl :-
rts
vdcFound:
inc vdcPresent
rts
|
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Since your detection routine is writing to a VDC register, i'd suggest reading a byte from VDC RAM, writing it back inverted, then reading it again. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
and i'd suggest to use a couple different bytes on subsequent addresses, so it doesnt fail randomly (or to be exact: fails much less likely randomly) because floating bus :) |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Yeah, use the auto-increment feature to write-read some magic words. =) |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
Quote: FWIW, currently doing:
ldx #0
ldy #5
stx VDCADR
:
bit VDCADR
bmi vdcFound
inx
bne :-
dey
bpl :-
rts
vdcFound:
inc vdcPresent
rts
probably I'm missing something here, but if d600 is open io you may get bits set at VDCADR just randomly? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
Indeed. And for more fun, its not exactly random, but depends on what the VIC fetched in the previous cycle :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Indeed. And for more fun, its not exactly random, but depends on what the VIC fetched in the previous cycle :)
True. I'll change that to vdcProbablyPresent and then read/write some into VDC RAM to be sure (with timeout on the polls). |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
why not just test at $d030, you set some used bit, and then test it if it stays the same for the entire next frame, then clear the bit and same. |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting Oswaldwhy not just test at $d030 $D030 is implemented by a couple of accelerators as well, so its presence doesn't say anything about the machine being a C-128.
Besides, see OP: "Easyflash emulation in 1541u2 doesn’t work in 2mhz mode." |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quoting Oswaldwhy not just test at $d030 $D030 is implemented by a couple of accelerators as well, so its presence doesn't say anything about the machine being a C-128.
Besides, see OP: "Easyflash emulation in 1541u2 doesn’t work in 2mhz mode."
For this particular problem I just want to detect the VDC chip. It has nothing to do with CPU speed. It's for dual-screen support in Eye of the Beholder. The map rendering on the VDC is almost completed now. |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting JackAsserFor this particular problem I just want to detect the VDC chip. It has nothing to do with CPU speed. A VDC is present if and only if the machine is a C-128, no? =) (Or do VDC-less C-128s exist? :-O) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11387 |
But what if i put a VDC in my C64? |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
Quote: But what if i put a VDC in my C64?
that points to autodetect then let the user change, then save settings not.to bother.him again. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quoting JackAsserFor this particular problem I just want to detect the VDC chip. It has nothing to do with CPU speed. A VDC is present if and only if the machine is a C-128, no? =) (Or do VDC-less C-128s exist? :-O)
I mean, it's easier to detect the VDC than accidently detect a C128 and assume the VDC is there which will corrupt SID. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: I mean, it's easier to detect the VDC than accidently detect a C128 and assume the VDC is there which will corrupt SID.
If the purpose is to use the VDC and your code doesn't care about other C128 features, then it makes total sense to detect just the VDC directly. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: If the purpose is to use the VDC and your code doesn't care about other C128 features, then it makes total sense to detect just the VDC directly.
My thought as well. I will not auto-enable the 2Mhz-mode in the presence of a C128 since the EF3-emulation on U2+ doesn't support that. I however do want to automatically detect the VDC. Enable the second screen with a menu config is just poor UX. Also it's not like there will be random chips in the D600-range. It's either a SID-chip, broken SID-chip, a VDC, a broken VDC or nothing. |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Another thing to note to tell apart VDC from SID (on top of using advanced VDC RAM access features) is that VDC has just 2 registers on the bus, with mirrors at mod 2 = 0. SID, otoh, has 29 registers, with mirrors at mod 32 = 0.
So accessing the mirrors as well might add some further confidence, especially when going for the 4 readable (read-only, in fact) SID registers $19 through $1c. |
| |
rosettif
Registered: Apr 2016
Posts: 10 |
Check for both $d02f and $d030 at the same time.
First write $ff into them and read back. Both must contain $ff then.
Then write $00 into them and read back again. One must give back $fc, the other $fd. (And even if either of them is implemented by any kind of accelerator, the other is not, or not exactly in this way.)
Looking for the VDC is not a good idea, since it can be removed from a C128, or faulty, which will work on even without it (and then it can't be detected, of course). If you still decide to check for it, then you should first initalize the chip before expecting an answer (which is not done by the machine, when it boots up in the C64 mode), that is slightly more complex to do than the other methods mentioned.
You might also detect the presence of the Ultimate Command Interface on 1541U2: if enabled, $df1d always contains $c9. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Check for both $d02f and $d030 at the same time.
First write $ff into them and read back. Both must contain $ff then.
Then write $00 into them and read back again. One must give back $fc, the other $fd. (And even if either of them is implemented by any kind of accelerator, the other is not, or not exactly in this way.)
Looking for the VDC is not a good idea, since it can be removed from a C128, or faulty, which will work on even without it (and then it can't be detected, of course). If you still decide to check for it, then you should first initalize the chip before expecting an answer (which is not done by the machine, when it boots up in the C64 mode), that is slightly more complex to do than the other methods mentioned.
You might also detect the presence of the Ultimate Command Interface on 1541U2: if enabled, $df1d always contains $c9.
Detecting the VDC is perfect. If it’s not there I will not use the VDC-functions. :) |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
Quoting rosettifIf you still decide to check for it, then you should first initalize the chip before expecting an answer (which is not done by the machine, when it boots up in the C64 mode) I guess that's mostly setting up display geometry and such?
Pretty sure a VDC presence check based on memory transfer commands would work regardless of display initialisation, no? |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
"If you still decide to check for it, then you should first initalize the chip before expecting an answer (which is not done by the machine, when it boots up in the C64 mode)"
I have used a c128dcr for ~10 years in c64 mode as main machine, and I know for a fact, that VDC ram is present and usable all the time without setting up anything. (As I have used it as extra 64k ram for coding)
edit: interesting fact is that the speed at which you can write to the VDC ram depends on what kind of ram chip you have :) I had an optimised routine with enough nops betweeen writes, then the chips got changed and it became so unreliable I had to put wait poll back. |
| |
rosettif
Registered: Apr 2016
Posts: 10 |
Quote: Quoting rosettifIf you still decide to check for it, then you should first initalize the chip before expecting an answer (which is not done by the machine, when it boots up in the C64 mode) I guess that's mostly setting up display geometry and such?
Pretty sure a VDC presence check based on memory transfer commands would work regardless of display initialisation, no?
Even the memory read/write operations will fail mostly.
Everything works well while using the GO64 command or the reset button (since once the system was in native mode before, the VDC is already initialized), but won't when holding down the C= key at powerup, or using cartridges (like IDE64 or EasyFlash) which force to boot in C64 mode. (Well, it may work sometimes though, if you have some luck, but not reliable.)
I discovered this when I wrote some test programs on my C128's a few years ago. I wasn't aware of it yet, as I was always testing them in either C128 mode, or after the GO64. I was surprised to see and wondered why all my VDC-related code ceased to work when powering up the machines in the 64-mode directly... So I started disassembling the 128-mode Kernal and found the part which performs the initialization. Then based upon that part, I wrote this small utility to fix this (the source code is also there):
VDC Init |
| |
Krill
Registered: Apr 2002
Posts: 2981 |
What kind of missing initialisation would let memory transfers fail? Something with RAM refresh parameters or so? |
| |
rosettif
Registered: Apr 2016
Posts: 10 |
I have absolutely no idea of the actual reason. Just the plain experience that my own codes are not working well without it.
I have four C128's, though all of them are the flat models (so it might differ on DCR).
Two of them have the standard 16K VRAM only, and the other two are upgraded to 64K with the add-on card (thus they use the RAM on the card instead of the original RAM chips). But the result is the same. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: I have absolutely no idea of the actual reason. Just the plain experience that my own codes are not working well without it.
I have four C128's, though all of them are the flat models (so it might differ on DCR).
Two of them have the standard 16K VRAM only, and the other two are upgraded to 64K with the add-on card (thus they use the RAM on the card instead of the original RAM chips). But the result is the same.
I already init the VDC properly, so based on what you say.
During the following, always poll VDC with timeout:
1) Initial detect by polling $d600 => VDC probably found
2) Init VDC to prepare for memory test
3) Do VDC memory test => VDC properly found |
| |
rosettif
Registered: Apr 2016
Posts: 10 |
Quote: Check for both $d02f and $d030 at the same time.
First write $ff into them and read back. Both must contain $ff then.
Then write $00 into them and read back again. One must give back $fc, the other $fd. (And even if either of them is implemented by any kind of accelerator, the other is not, or not exactly in this way.)
Looking for the VDC is not a good idea, since it can be removed from a C128, or faulty, which will work on even without it (and then it can't be detected, of course). If you still decide to check for it, then you should first initalize the chip before expecting an answer (which is not done by the machine, when it boots up in the C64 mode), that is slightly more complex to do than the other methods mentioned.
You might also detect the presence of the Ultimate Command Interface on 1541U2: if enabled, $df1d always contains $c9.
Just a marginal note to my own opinion here: better to use $fe instead of $ff, in order to not enable fast mode.
The very same fast mode bit is not only used by the C128 (and the Turbo Chameleon, maybe the U64 as well), but also some others like the TDC or the MEGA65, which may have some trouble with it, if also a 1541U2 added. (E.g. with TDC and U2 on the same machine at once, and the fast mode bit being enabled at any time, it completely freezes.) |
