Emulation questions

[MADrigal]

Question: why do you say "delay of 8 cycles" when there are 4 "NOP"'s only between subsequent STA/STY commands? Does every NOP count 2 cycles?

EDIT: found the answer myself. Google is my best friend

http://www.atarimax.com/jindroush.atari ... c.html#NOP

[carlsson]

I've got a Diagnosticart in case some testing on real iron is required.

As for writing to the VDP, I thought as long as interrupts were disabled, the VDP could handle subsequent writes without CPU delay on this 2 MHz machine. I seem to recall it being a bigger issue on the 3.5 MHz Z80 machines. At least I didn't see any glitches on my own programs on real hardware as long as interrupts were not enabled, only once I kicked the interrupt to start, I got all those weird display errors before I also moved all VDP updates into the interrupt service routine. I think a couple of the original CreatiVision games don't utilize the interrupt and would write to the VDP whenever they like, just like this diagnostic routine does, but I could be wrong as I haven't studied the old games more than very briefly.

[@username@]

I am a little confused as to why the interrupt is important here.

A normal ISR has a limited amount of time, or the machine dies - sometimes quite literally.

In the case of the VDP int flag - that's all it is. It's a convenience to a) tell you when the display has reached the end and b) keep some kind of reasonable timing without having to count cycles. The flag is only cleared on subsequent reads of the the status register. Which means you can neglect to read it and continue to take the kids to Disneyland, have a round of golf etc. and come back and read it.

What does make a lot of sense is updating VRAM as soon after the int flag is raised. However, you have no way of knowing when the raster has reset to top, unlike most modern machines - so, to me, somewhat irrelevant. You just need to write to VRAM before the raster needs it too.

The delays on reading and writing VRAM make sense too. In the write to the control registers, you are only talking to the VDP - so logically it should not take more than a few cycles to propagate. When reading or writing to VRAM, things need the 8 cycles to allow time for the VDP to fetch or send to or from VRAM.

@mobsie - Why would sending the mode register 0 make any difference? Does something else happen on a mode reset?

@carlsson - If you could check what happens in the keyboard diag when you press shift and A? In emulation, it seems "confused" if more than one key is pressed in the same grid at the same time. This could be just PC being too quick.

EDIT: Attached the keypad matrix, confirmed with the Keyboard Diag program

[Mobsie]

i read that sometimes the VDP in an "unknown" mode and interpret the bytes you send wrong. When you send first the "0" then he reset and interpret the next bytes correct.

The control register you can read or write at any time because the VDP don't "use" them. But the VRAM he use when display in Mode "on" and he display the screen. When display is set to "off" or in the VBL you can write as fast you want.

Strange english, difficult to explain.

[carlsson]

Test results from the keyboard diagnostic:

The keys CNT'L, SHIFT, equal sign and -> "double" as fire buttons, meaning the program displays both the key pressed and a black rectangle matching the corresponding fire button. Likewise when pressing the four fire buttons, the corresponding key is displayed:

Left controller: upper fire button = CNT'L, lower fire button = SHIFT. Worth noticing here is that for SHIFT, the keyboard symbol is displayed prior to the black rectangle matching a fire button, while that for CNT'L, the keyboard symbol is displayed after the rectangle. This is true both if you press the keys on the keyboard or the actual fire buttons.

Right controller: upper fire button = Equals sign, lower fire button = -> symbol. In this case, the equals sign is always displayed prior to the rectangle and the -> sign is displayed after the rectangle. I suppose it means the PIA (?) decodes the equal sign and SHIFT keys before the joystick, but decodes the CNT'L and -> keys after the joystick?

As for the SHIFT test, every key except "1" and possibly "CNT'L" on the left keypad generates garbage when pushed with SHIFT held down. The garbage varies:

Code: Select all

SHIFT + 2 = 3624RCSQEXA
SHIFT + 3 = 324RCS
SHIFT + 4 = 3524RCSQWZ<-
SHIFT + 5 = 54QWZ<-
SHIFT + 6 = 62QEXA
SHIFT + Q = 6524QEXAWZ<-
SHIFT + W = 5T4RQEWZ<-BG
SHIFT + E = 6T2RQEXAWBG
SHIFT + R = 3T24RCSEWBG
SHIFT + T = TREWBG
SHIFT + <- = 54QWZ<- (same as with 5 above)
SHIFT + A = 62QEXA (same as with 6 above)
SHIFT + S = 324RCS (same as with 3 above)
SHIFT + D = 365TVD
SHIFT + F = VCXZBF
SHIFT + G = TREWBG
SHIFT + Z = 5V4CQXWZ<-BF
SHIFT + X = 6V2CQEXAZBF
SHIFT + C = 3V24RCSXZBF
SHIFT + V = 365TVDCXZBF
SHIFT + B = TVRCEXWZBGF

It should also be added that in mode 2 with the onscreen keyboard already in place, pressing the lower fire button on the left joypad only registers as the SHIFT key, while the upper fire button registers as fire instead of CNT'L. Likewise pressing CNT'L displays as upper fire button, not CNT'L itself. I believe it has something to do with what I wrote above about the rectangle displaying prior or after the keyboard symbol, and that in this mode, the diagnostic program only reads one input value instead of the sequence of two values.

Similarly, pressing the lower fire button on the right keypad registers as a real fire button instead of arrow right, while the upper fire button registers as equals sign instead of fire button. The same applies here, that pressing -> will display as lower fire button, analogous to the above writing.

This behavior by the way doesn't change a bit if SHIFT is held down.

Worth noticing is that a few keys generate different shifted sequences if one uses the Moving-Key keyboard. I don't know if it is of any importance here, unless you specifically will include emulation of the add-on keyboard which for all normal attempts and purposes is supposed to behave just like the regular touch keyboard, just this diagnostic program having fits with it.

[@username@]

Hey, thanks for doing such an exhaustive test!

The good news is that what you are saying lines up pretty well with the emulator, with the exception of me (and everyone else:)) having the SHIFT and CTRLS switch from side-to-side. I'll amend this, if it doesn't screw up keyboard play too much.

If you take a look at the matrix I posted a couple of replies above - it makes it quite simple to see how the keyboard matrix works from within the CV.

It also explains why poor old Tom had to search out a couple of keys for Salora mode. The Salora and Laser have an 8 way mux, rather than the basic 4 mux we have here. Fortunately for me, the CSL only needs cooked values mapped.

As you appear to have easy access to your CV, would you be interested in helping me update SM Bloader to include the CV wave format?

Thanks again for your help with the keyboard.

EDIT: Attached 0.2.9.8 binary for Win x86 - it may contain debug still! At least the PIA makes it to the main program

[@username@]

Also from my memory (you could confirm or reject this), the diagnostic programs do not call the BIOS, and they have their own character sets, often not matching the "usual" ascii codes. For example, on the video diagnostic program you can only find ASCII data for the letters "R,E,A,D,Y,?". Is this correct?(

The Video Diagnostic cart uses it's own font - but only because it uses 40x24 mode. So it has READY? and the colours there.
It also uses BIOS throughout for keyboard input.

[@username@]

Well, I've had a great afternoon with the Video Diagnostic cartridge!

It has taken me a fair old while to track down the problems. Both were in the DRV9918 driver of emulib. The fifth sprite detection was coming back with nonsense sprites. Believe it or not, the solution was a couple of typos in the emulib source code! As simple as --C should have been C--.

The second issue, will probably never be fixed. Its that the CS flag is never set from emulib. For the purposes of my emulator, it's not an issue, as no programs seem to ever check it anyways. Likewise, it would appear nothing checked the fifth sprite ID in the ColecoVision, MSX or CV!

EDIT: Now on sf page - new versioning too!

[Mobsie]

That's Great, thank you. The CS flag is mostly Not used, the Colecovision for example has Special BIOS functions to handle this.

[@username@]

There's a missing ROM dump, that is the CPU program. The EPROM got damaged when unsoldering. It's quite a long story, no need o enter into details.
Anyway I have partial dumps of the ROMs, which were made by me and other people, using a variety of EPROM readers.
Each and every byte misses bits 1 and 6 due to a damage in the EPROM wires package.

I have programmed an useful tool that displays the single bits in each byte, also visually. And you can change the bits values by simple clicking on them.
I would provide the EPROM and the tool (which is currently in use of a few MAME devs, anyway), if you want to have a look.]

The first question is how far have they gotten with it?
If they are near completion, then for me there's no point starting.
It would be interesting to see the dump, if only to try to work out how much is reasonable.