CreatiVEmu Forum

As it says on the tin, does a comprehensive technical document exist? I did a fairly through search of the forums and the internet in general and cannot find a document about the guts of the system. Be this as it may, I think I have reverse engineered most of how it works from a disassembly of the BIOS I made.

From the BIOS I have deduced how the SN76489 is connected, and how the controllers and keypads are read. I compiled a quickie document on how everything is connected up in the console so I have a base to work from. I can post this if anyone wants to see it.

This is for an FPGA Creativision I am going to attempt to make. I don't expect this to take more than a day or three, since I already have 6502, TMS9918a, and SN76489 cores already from the other systems I have done. Just need to drop in the unique things (6821, controllers) and it should be good to go.

It will be NTSC for now since I'm in the US and don't have an easy way to display PAL video yet; hope the games won't mind. (They should be 20% faster than normal, but otherwise I suspect they will work, since I doubt they used much of any cycle timed code and the '9918a lets you read/write during rendering).

This will be my 15th or 16th system I have implemented on an FPGA, so I am not expecting too much difficulty. I just am a bit unsure around a few minor things, like what bits 4, 5, 6, and 7 do on PORTA (1000h). I know at least a few of these go to the tape player add-on.

The other minor issue I am unsure about is the cartridge mapping. I cheated a bit and looked at the source code to Funnymu to see how the ROMs map into the address space. It doesn't look too complicated but I might have a few questions on how to streamline this maybe.

Checking out the controllers was kind of interesting. I found a few pictures of the PCB on the internet and some internals of the controllers and determined it is similar to the Intellivision in that pressing a button causes 1 or 2 output lines to be pulled low, instead of there being a 1:1 button mapping. Upon inspection this is indeed what's going on. Each key has a unique 2 bit code, while the controllers are just 1 bit per direction (to allow diagonals and the fire button).

As mentioned previously, I disassembled and did some commenting on the BIOS to see how it was interfacing with the 6821. They use the CB1 and CB2 to interface with the sound chip which I thought was rather clever; The keypads/controllers are simply read in the usual way with 4 column outputs and 8 data inputs. IRQ must not be used, since it points to the reset vector, and NMI is connected to the TMS9918a.

I found a memory map which seems to be pretty decent, and from the PCB scan I saw, there's only really three TTL chips on there doing any kind of mapping so it cannot be very complicated.

As for the sound chip, it's clocked from the 2MHz CPU clock, and not the VDP clock I take it.

i send you PM

I tried to send you emails yesterday, but they were rejected by your spam filter.

I have docs to send you such as data sheets, memory maps, etc.

Regarding the sound chip @ 2 MHz, that is what I noticed as well. Some of the older emulators generate too high frequencies compared to real hardware, so it can be good to check.

MADrigal wrote:I tried to send you emails yesterday, but they were rejected by your spam filter.

I have docs to send you such as data sheets, memory maps, etc.

Sorry about that. I will pm you an alternate email address you can try. My ISP is a pain about its spam filter, unfortunately.

That's great. Got your PM, I'm now sending you an email

This is the evidence that shows the sound chip is clocked at 2Mhz.

I have compared to the actual frequencies, against the table held in BIOS (<FC80/>FCAA) and BASIC.

The chip can go higher and lower, but perhaps this was considered the 'safe zone'.

Thanks for those docs, the schematics were helpful. There's a page missing though; the page with the sound chip and 6821.

I have some edge cases I found, like what happens if you read the write port or write to the read port on the VDP. (Reading 3xxx will cause the VDP to latch open bus data; writing to 2xxx will cause a bus conflict since the CPU and VDP will both drive the bus. while not terribly harmful, this probably shouldn't be done.)

Update: I managed to get my FPGA Creativision working for the most part. Sound is still a bit iffy- it works fine but sometimes notes/sounds continue out and do not silence. I am poking around a bit on that. I implemented keypad input and controller inputs via SNES joypads. start/select act as the two "Start" buttons on most of the game overlays I saw pictures of.

Video seems OK, and I know the answer now to the question on how games handle refresh rate differences (PAL/NTSC). The answer appears to be some games have software delay loops (pinball) while others use the IRQ from the VDP (Planet Defender). The majority appear to use the interrupt.

Most games appear to function properly. Some games have issues, however. I am going to add a PAL/NTSC selector to see if dropping the frame rate to 50fps fixes those games. The two games I had trouble with were Planet Defender (a bit of flashing chars at the top of the screen for score, which stops when you stop scrolling the background) and the Tennis game, where after you play once it locks up.

Another oddity I noticed. I believe the BIOS I have is hacked, because it does not show the logo, and only flashes the year real fast before the game starts. Once a game is loaded, it will not "cold reboot" unless you clear some bytes in RAM. This appear to be normal- it's for a cold/warm restart (it appears some games show a demo when first powered on, and you have to hit reset to stop the demo and let you start a game.)

kevtris wrote:Another oddity I noticed. I believe the BIOS I have is hacked, because it does not show the logo, and only flashes the year real fast before the game starts. Once a game is loaded, it will not "cold reboot" unless you clear some bytes in RAM. This appear to be normal- it's for a cold/warm restart (it appears some games show a demo when first powered on, and you have to hit reset to stop the demo and let you start a game.)

This is normal for most games. The RESET button just forces an NMI, which on re-entry, tells the game to go to GAME TYPE selection.
The no logo is also normal for a non Creativision console. I guess it was cheaper just to blank the logo than re-write the BIOS.
I've attached my BIOS disassembly, I used it to write the emulator and do the low level stuff for CC65, so some of the comments may be nonsense, in general it's ok.

@username@ wrote: This is normal for most games. The RESET button just forces an NMI, which on re-entry, tells the game to go to GAME TYPE selection.
The no logo is also normal for a non Creativision console. I guess it was cheaper just to blank the logo than re-write the BIOS.
I've attached my BIOS disassembly, I used it to write the emulator and do the low level stuff for CC65, so some of the comments may be nonsense, in general it's ok.

Aah, so they did use NMI. I just use reset though because NMI and reset both point to the same vector, so there's not much difference.

I managed to fix the broken sound- it's due to a bug in my 6821 verilog. The tennis game locks up after you score the first point, so I saw the PC was getting stuck and disassembled the ROM to find where it was hanging up. It gets stuck here:
This was somewhat strange; I recognized the address FE77h which is the BIOS sound write call. They are using the accumulator to store one of the counter values. FE77h trashes the accumulator, though! That's why it never could exit this loop. My BIOS had this: (mind my comments, hehe)
I checked your disassembly and it matches mine, so this is right. The problem is I am not returning the proper value in 1002, and instead returning the keypad information instead. (I kind of cheated on that, guess I will fix it so it works properly).

Update: I changed my TMS9918 so I can use both NTSC and PAL now. This fixed the graphic glitching in Deep Sea Adventure / Planet Defender. Both of those games have "disappearing terrain" though, which I am not sure if this is normal or not. I remember reading something on this forum while I was doing research which said this was normal I think. (the graphics on the "mountains")