[CSDb] - User Forums - Detect C128 in C64-mode without exploiting 2mhz mode?

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Detect C128 in C64-mode without exploiting 2mhz mode?

2020-04-03 08:04

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.

... 40 posts hidden. Click here to view all posts....

2021-09-29 20:48

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.

2021-10-10 20:32

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.

2021-10-11 07:14

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. :)

2021-10-11 10:25

Krill

Registered: Apr 2002
Posts: 2981

Quoting rosettif

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 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?

2021-10-11 17:16

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.

2021-10-12 00:11

rosettif

Registered: Apr 2016
Posts: 10

Quote: Quoting rosettif
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 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

2021-10-12 01:46

Krill

Registered: Apr 2002
Posts: 2981

What kind of missing initialisation would let memory transfers fail? Something with RAM refresh parameters or so?

2021-10-12 02:11

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.

2021-10-12 08:54

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

2021-10-17 04:15

rosettif

Registered: Apr 2016
Posts: 10

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.)

Previous - 1 | 2 | 3 | 4 | 5 - Next

Refresh

Subscribe to this thread: