Unbelievable - a second HP B7XX !

Yesterday I got a second High Profile machine: It's a regular B710 (@ right)!
The PSU was defective - but it was easy to repair that.

Who in the world owns two HP-machines? ;-)

The differences to the Prototype (@ left):
Keyboard in beige/green color, sticker instead engraved Commodore, plug in the monitor-power-cable, only 128kB RAM, three 2764 ROMs on adapter-board

It's made in germany 

I have to clean it!

A new computer for my collection!

A new computer for my collection just arrived.
...but it hasen't much RAM inside ;-)

The machine has the orignal MPS 6540 RAMs and MPS6550 ROMs!
It's in a very good condition:

Oldschool Programming-tool ;-)

Today I got a very old programming tool from the USA - the 1977 TI Programmer.
First I cleaned it and changed the accumulator against a 9V-battery:

This very cool machine is able to write my nickname with the TI-custom chip:

 

Now it looks like new:

 

 

Raster IRQ & collision working

The last things from my to-do-list are now realized:

- sprite-sprite-collision detection
- sprite-background-collision detection
- collision-interrupt enable / flag setting
- raster-interrupt enable / rasterline setting

 

I coded a simple routine to test the raster-interrupt. It changes the background (38 column-mode to see the frame at the sides) and framecolor at rasterline 00, 6f and fb. This works but some times the screen flickers a little bit - it's not perfect ;-)

 

The collision-detection works perfect. After a whole screen the bits of the involved sprites were set in the colliosion registers. Also the source-bits in the IRQ-flag register were set. If one of the irq-mask bits are set, an interrupt will be outputted for only 15 us because clearing the IRQ is not possible.
My Atxmega don't recognise a write to the flag-register!
I clear the raster-irq-flag and the collision-flags after one rasterline.

Now PAC-MAN can eat ghosts:

 

Soccer now runs with players  on the field. The game uses sprite-multiplexing.

This doesn't work properly because I update the sprite-data only 3 times on a screen.

I tried to update the spritedata everytime a sprite starts in a rsterline but this reduces the refreshrate too much (10-12 Hz).

 

 

Donkey Kong now works, but some colors are wrong - I don't know why?

The game has some sprite-errors (Kong) and runs very slow.

I think the speed of many games like Donkey Kong, GORF or int. Soccer depends from the VIC-rastercounter. The VIC draws the screen 50 times per second (PAL) - but the xmega only do it about 20 times / second.

 

Rastercounter / Raster-IRQ

With some changes @ the XMega I implemented the last VIC2-details:

 

- VA14/VA15 inputs now @ Port R0, R1 (crystal-inputs) - I use the internal 32 oszillator with PLL

- display reset direct to VCC

 

 now I have 3 new I/Os free:

 

- output enable for the LVT245 databuffer to the XMega

- direction of LVT245 combined with write to GAL (there added to write to RAM)

- IRQ with NPN transistor

 

Now some games like GORF, Jungle Hunt and DigDug are running and International Soccer starts (without players on the playfield?) ;-)

 

The rastercounter works exactly for every line!

I tested the rastercounter with some small assembler-routines like this (38 column mode):

 

Here is the timing @ the logic16:

 

- At first the Xmega sends RDY to the GAL (0)

- if R/W (1) is high the RDY goes to the CPU (2)

- after 3 us the CPU secure stops and the XMega sends AEC to the CPU-adressbuffer (3) and OE to his Xmega adressbuffers (4)

- Than he reads the rastercounter and sets the transistor (7) -> CPU-IRQ goes low (8)

- the Xmega disable the databuffer outputs (5), sets the write line to the GAL and the direction of the databuffers (6)

- than the controller enables the databuffers to write the IRQ-flag to the RAM (D019).

- now the XMega disables the databuffer-outputs (5) and disables the write/direction-signal (5).

 

I tried to set 5 and 6 at the same time high after writing, but than the system was unstable.

Now I disabled the outputs 30ns before end of write (negative data-holdtime) - but thats not a problem because of low cmos-loads the datalines are stable long enough! 

 

VIC-Emulation finished!

VIC2-Emulation in the Xmega 128 finished:

 

- refreshrate between 24 and 28 Hz

- userfont with 10 Hz refresh rate

- multicolor, enhanced color, bitmap, multicolor-bitmap

- 38/40 column + 24/25 line with softscrolling

- screen disable, with only short 4us CPU-stops to check if enabled - so jiffy-DOS should work!

- sprites with multicolor, expand x/y, background priority

- sprite-data with about 75 hz refresh

- illegal screen modus

- all CPU-stop are shorter than 30 us / 42 us is OK for disk-loading with normal speed + screen on.

 

Not implemented: Raster-IRQ, sprite collision detection -> Emulation is possible, but I have to write to ram for this - and now the xmega only reads!

 

I'm so happy: Loderunner is full playable - it don't uses collision detection ;-)

 

With Pac-Man I can reach new world-highscores, because I cannot die ;-D

 

 

Pipes is full playable - it uses multicolor, but no sprites:

 



 

Multicolor-bitmap-testscreen:

 

 

Donkey Kong reaches only the start-screen:

I think many games needs the raster-register!

In Pole Position only the startscreen works.

 I will add the second CIA / 7406 to test some games from disk...



Added scrolling, bitmap & multicolor-mode / PLA OK

Now I implemented successful the bitmap-mode to my Xmega-VIC2.

Also I added 38/40 column and 25/24 Row modes with soft-scrolling horizontal and vertical.

Scrolling is possible in character and bitmap-modes.

 

 

This is the small basic-program to test the bitmap-mode with the screen above:

 

I added the multicolor-mode to my Xmega-code and now PAC-MAN looks right - but sadly still without the sprites ;-)

 

AMC is not in multicolor-mode but the colors weren't OK.

Now the colors are great:

 

The Commodore Diagnostic now writes that my PLA (82S1) is not bad (I think it is because I implemented CHAREN).
In the second RAM-Test the screen goes crazy, because I use the RAM from D000 to D3FF as VIC-registers. The SID and the 2nd CIA are BAD because they are not present. The first CIA is BAD because of the missing TOD.

Added enabling character-ROM

Now I added the CHAREN signal of the port 0001 from the 6510 to enabling the character ROM.

PAC-MAN and Pipes uses this to read the letters and numbers from the built-in-font to save memory in the cartridge-rom.

I use now 2 GAL22V10 because I need all the outputs.

The CHAREN is detected in the second GAL and stored in a D-Latch like LORAM/HIRAM.

 

PAC-MAN uses multicolor-textmode - I have to add it in the Xmega now :-)

 

Gameplay-Video - now with Joystick :-) but without sprites ;-(   PAC-MAN-gameplay

 

 

Pipes uses CHAREN too - and works now perfectly!

Real gameplay on my LC64 :-)

After finishing the user-font-implementation I tested some ROM's:

 

The Commodore Diagnostic-Cartridge (without the test-dongles) runs, but at the second RAM-test the screen disappears... - it comes back at the next count.

U2, U18, U17 are bad because they are missing ;-)

And maybe U1 is bad because in the 8520 is no TOD.

And the 6510 is OK ??? - It's a 6502 :D :D :D

 

AMC is full playable because it don't uses sprites :-)
It only works with user-fonts - and they are working perfectly!

YouTube: AMC Gameplay

 

 Pac-Man runs but the start-screen looks crazy?

 

It's real FUN to play without sprites!

You only see the maze and eating the cakes - but you don't see Pac-Man and the ghosts :D :D :D

 

YouTube: PAC-MAN Gameplay  (without sprites & without Joystick port 1)

 

Pipes has some screen-errors but it runs and is playable...

The Terminal-Interface Cartridge works:

A real MSX for my collection ;-)

I got a real MSX 1 - machine!

It's a Yamaha CX5M with the built-in SFG-01 FM-synthesizer-unit.
I also got the YRM-103 DX7-Voicing Program. With this I can plug in my DX7 and edit the FM-sounds ;-)

Because the power supply was missing I took an external HD-supply with +12V / +5V and soldered it to the very special 13-pin-DIN-plug! With a Murata DC/DC converter I generate the -12V in the CX5M (on the board it generates -5V for the 3-voltage-DRAM's).

I built an audio-cable for the mini cassette recorder and now I'm able to load and save.

The SFG-01 sound-unit was easy to update to the SFG-05. I only needed to change the 16k ROM to the new 32k EPROM and add an extra wire for A14.

 

The CX5M uses the old TMS 9929 with 8 1-bit-DRAMs:

 

VIC-bankswitching & user-fonts

Today after the hardware is nearly finished I worked at the VIC-emulation.
I added the VIC-bankswitching (VA14, VA15) with 2 inputs in the Xmega. My xmega-VIC can use the RAM under ROM for screen-memory or userfonts - like in the real C64.
Userfonts are now possible:

The xmega detects the characterset-page-switching and loads it completely from the RAM in the xmega-RAM.
After that before every screen row the xmega loads 32 bytes of the actual font - so that about 10 times per second the complete userfont will be new loaded, to get possible changes of the font.
The whole xmage-RAM-downloading of the screen, the colormemory, the register and the userfont steeles the 65c02 only 35 milliseconds of a second !!!

Real CIA + CPU-Port-simulation

Now I found out that there exists a CIA in PLCC !!!
It's the 8520PL from the Amiga 600/1200. The only difference to the 6510 is that CSG changed the TOD to a 24-bit timer. But who need the TOD in the C64?

 

With the 8520 I can run the nearly unmodified KERNAL. The only thing I have to change is the PAL/NTSC detection, because I have no VIC and the KERNAL hangs in a screenline-read-loop.

 

I added a GAL16v8 that detected (together with A8-A15 from the GAL 22v10) the write to the CPU-port at $01 and stores D0 and D1 in two D-latches. The 16v8 gives LORAM/HIRAM to the adress-decoder in the 22v10.

Now I can turn off the BASIC and the KERNAL like in a real C64.

Also I burned Handic's MON-64 in the 32k-eprom before the basic and I can activate it by the EXROM-input of the GAL.

I wrote a small program (see below) to test the writing under the ROM, deactivating it and read from the RAM. - it wokrs !!!

CPU-Timing measurements

Today I made some measurements with the Rockwell R65c02 @ 4.096 MHz to check the system-timing, to verify the CPU-datasheet and in the last picture to compare it to the WDC.



Phi0(in) to Phi2 - 20 ns/cm -> 14 ns delay

Phi2 to adress - 20ns/cm -> 37 setup / 30 ns hold time

Phi2 to data - 40ns/cm -> -20 write data delay / 85 ns hold

Adr to CS - 20ns/cm -> 10 ns delay (15 ns GAL 22v10)

Phi2 to CS - 40 ns/cm -> CS time = 235 ns 

CS to data - 40ns/cm -> 145 ns before / 55 ns after CS high

WDC W65c02
CS to data - 40ns/cm -> 125 ns before / 50 ns after CS high

Xmega VIC2 replacement

Today I returned to the VIC replacement. The V9938 will be used later for my homebrew design.

Because the Atmega at the userport is limited in speed and kernal (FFD2) compatibility I decided to take an large AVR to read the SRAM without help of the kernal.

I tested the Xmega 128 with the 3.2 inch 16-bit display.

The Xmega is specified for 32 MHz. I tryed 64 MHz successful but I think 48 MHz is enough for a 25 Hz screen refresh rate.
The Xmega halts the CPU, disables the CPU-adress-buffers, enables the xmega-buffers and reads the VIC-register (there is RAM), one screen-row and one color-row.
Each reading sequence is about 16 us -> fast enough for disk load and save! (max. 42 us is allowed, because of the original VIC2). Than the Xmega checks the register for screen base adress, backgroundcolor, characterset/base and prints one row to the screen.
The CPU halts 1940 times per second - in total the CPU stops 42us of a second - not noticable ;-)
I got a screen-refresh-rate of 26 Hz.
Later with sprites it will be a little bit slower - or maybe I try the Xmega @ 56 MHz.

The Xmega runs with 3.3V so I need two HCT245 buffers to raise the adress-bus to 5V.
To read the 5V databus with the 3.3V Xmega inputs I use a LVT245 buffer.
I ANDed RDY from Xmega with the RW=READ so the CPU will only stop in read-cycle. This is nessesary because the CPU-databus must be input and not in conflict with the SRAM output.

To readout one byte from the RAM the HCT245 needs about 10ns, the GAL max. 15ns, the SRAM 15ns and the LVT 4ns! - I need only 3 NOPs = 63ns in the Xmega - very fast!

Now with the Rockwell CPU all is perfect - with the WDC there are again stability issues!