Friday 27 October 2017

Game#7 and #8 Completed : Basketball and Football

After a short hiatus mostly down to an illness of one of our dogs, who sadly didn't get better, the last couple of games I've finally got round to finishing off.

They are very similar games and share a lot of code. Basically it is you vs everyone else and you either have to reach the touchdown line, or get a clear shot at the basket at straight on or 45 degrees.

Players take it in turn to attack, there is no defence control.

Monday 23 October 2017

Last lap

Having not done a great deal over the last couple of days, I've had half an hour to devote to it this evening.

This has involved writing the 'throwing' code for Basketball, so the ball has to be thrown at 90 or 45 degrees to the basket and isn't blocked.

Apart from a couple of tweaks I'm considering, that just leaves the defender moving code to be written. First is fairly simple, the system allows three lives for each game and for Basketball/Football I'll put this up to more like 6 or 7. The second is whether to fail the player or not if they go off the top or bottom of the gaming area.

So far the code for the two sports games occupies just over 3 pages, which is fewer than I expected.

Saturday 21 October 2017

Game#7 and Game#8 in progress

As you can see, some progress has been made on the Basketball and Football games.  Here we see the Quarterback approaching the Defensive Line - it's modelled on the Mattel Game pretty much. Much of the basics is there, it flips from side to side depending on whose turn it is. I might change it so that there are more than 3 goes each this game perhaps.

You can't play this one yet.

There are three things left to do to complete ; firstly the collision between the player and the defence, at present you can just run through them. Secondly, the scoring attempt in basketball (you can already score a touchdown) and thirdly the player movement.

The topmost PCTR is at $67F which means six pages left. If I have the time, memory and inclination I'll change one thing from the game, viz. that the game speeds up as time goes on. This isn't difficult, I just haven't done it.

Friday 20 October 2017

Game#6 : Superman completed

Superman, the last non sport game, is now completed.

It's not as obvious as most of the other games. The object is to catch the dragons that fly backwards and forwards (you will hear a beep when you catch them) and transfer them to the dungeons (a white noise). You have to fill the dungeons to win in the fastest time (the clock counts down). However, the dragons periodically escape the dungeons and so you have to keep them in and chase them.

It's more infuriating than you think ;-)

The ROM is about 2/3 full, which leaves 9 64 byte pages to do the remaining 2 games (the others are mostly 2 or 3 pages), which will probably be a modified single game, having spent time looking at Mattel Football and Basketball there is a lot of commonality - the difference is that in Football you have to get to the goal area and in Basketball you have to get a clear shot at the basket.

Thursday 19 October 2017

Javascript Cosmos now has Sound Effects

Only beeps and white noise, but they are there :)

I used a tool JFXR which was a java port of BFXR (requires Flash ....) I might redo it, the beeps are sine ones so sound far too nice and not 8 bitty enough - or 4 bitty enough for that matter.

Quick Fix

Noticed Asteroids and Space Invaders had both stopped working. I'd moved the common new turn code into page 3, but forgot it had a JSRP in it ; this made it into a JMP which meant code after that wasn't being run, hence the turn wasn't being initialised.

Also done the holograms for Superman, Game#6, and spent some time viewing youtube videos of Mattel Football and BasketBall which seem quite similarish in many ways ; you either dodge the bad guys to make a touchdown or to get a shot at a basket. I think the games are sort of going to be alternate attacks, rather than the whole counting the yardage thing that they do in the US.





Game#5 : Destroyer completed

 So, you can now play Destroyer on the Cosmos a-like. The idea of this game is that the two ships fire at each other. You can take 4 hits before sinking, and there are as many ships as you want to sink on the other side.

Quiz of the week: The pictures show the two holograms (this is another "Game Over" hologram). Guess which one I drew and which one I found as a bit of artwork and borrowed :)


Third go at it.

Cannon movement patterns in Destroyer
Sometimes I'm too fussy.  I've been working on the shooting patterns on Destroyer - the game that's described in the Patent.  Two ships shoot at each other across a crowded room.

Doing it efficiently and reliably has taken me some time, and I actually chucked away two previous working versions. But I'm happy with number 3 and it seems to work reliably.  It's fiddlier than it looks in COP444 assembler when you are trying to fit it into about four bytes of ROM. Not only do you have the varying pattern at the top, but you can't fire on row 1. All this takes precious memory.

Having said that all that's left of Destroyer is to add the collision detection and the scoring and to make the opponent firing slightly more sensible. (It just has bodge test code at the moment) and the fill percent is still only 54% of the ROM. I had the same thing with Microvision Space Invaders, worrying about memory space and ending with half of it unused.

In other, er, news, I've tweaked Outlaw. It's now the same game, except the player controlled is on the left hand side, which I think is more normal. Destroyer has the player on the left by default.

I'm presuming all the '2 player games' are turn taking rather than firing at each other, there's only one set of controls ....

Tuesday 17 October 2017

Game#4 RoadRunner completed

Even more games - this one a real quickie. It's a very simple game, you have to dodge the vehicles (which flash) and collect the cash (that doesn't flash)

As its a RoadRunner game it's probably birdseed and rocks or something. There's very little about this game - there's a 2600 game with the same idea - scroll rightwards dodging/collecting, and a Tiger LCD handheld.

This game is unique in one way - I fitted it all in one page (that's 64 bytes). It wasn't cut down at all ; it does everything I wanted it to.

So that gives me 15 pages for four games, which is looking much more like it :)

Game#3 Outlaw complete

I can't aspire to such high resolution on the Cosmos
So after a couple of days doing nothing, two games in one day. This one is Outlaw, the shoot em up avoiding the cactus game.

In other, err... news, with a bit of fudging and fiddling I've saved a page of ROM memory ; it is now half full.

This gives me 16 pages to do Roadrunner, Destroyer, Superman, Basketball and Football.

Still no sound.

There's a permanent link to the current Javascript build in the top right.

Outlaw in development.

Outlaw, game 3 is under development. One player only here, and as with Invaders a few posts back, currently very one way - the other gunfighter doesn't actually fight back.

The ROM is now slightly less than half full. I reckon the opponent code for this game will take a page maybe. That will leave me with 6 games (DodgeEm, RoadRunner, Superman, Seawars, Football and Basketball) and 15 pages left, or about three each.

I'm beginning to wonder about what games were there and what were completed. Roger Hector (interview with Atari Compendium) is very explicit:

Internal Atari Document
A: Yes, that was pretty much the end for me.  We had conceived of and
patented a whole new technology (mass-producible holographic displays), and created a finished tooled product that was supported by 8 finished games (Asteroids, Basketball, Destroyer, Football, Outlaw, Road Runner, Space Invaders, and Superman).

Q: A press kit labeled Electronic Entertainment has a flyer that lists 9 games, and a letter that mentions there were 8 (but only lists 7).  Two different titles mentioned were Dodge 'Em and Sea Battle.  Were either of those being worked on, or were they simply vaporware?


A: There were a number of brainstorming sessions that considered other games, but the original 8 were the only ones worked on.

This is supported with an internal document (see above). I think I'm going to go with Hector here. So Dodge'Em and Sea Wars are off and replaced by Destroyer. I'm guessing this was a simpler game, it sounds simpler certainly (it's loosely described by Roger Hector).

With this it starts to look reasonably plausible. Reasonably, I must add. Of the five (now) incomplete Destroyer, Road Runner and Superman don't worry me too much. I'm wondering how much code Football and Basketball share.

Game#2 Space Invaders working

.... as per title.

It is working as far as I'm going with it ; the invaders march backwards and forwards and down, fire at you, you shoot back.

They only fire one missile between them. I could increase this but it might become very difficult.

Note, the Javascript version doesn't have the sound effects , yet. The C version does but it is classic 8 bit stuff ; short beeps, long beeps and white noise, and that's pretty much it.

I think much of my guesswork about the hardware is probably not far off, but the sound system ; other than it's a second processor I know nothing.

In which I cannot count

There's only one thing wrong with the post what I wrote a couple of days ago.

There's actually nine games not seven.

Some consequences, most things are designed for sevens, which has meant some rearrangements of the jump tables. I have two of these because of the way JQID works ; basically it changes the LSB of the PCTR according to ROM memory, there is then a dispatching table which goes to do each games code. So a bit of rearrangement.

I also made Space Invaders into the worlds hardest. They now have that zig zaggy movement so well known by arcade fans, but it's a little bit fast so I'll have to slow it down a bit, well a lot .... I haven't uploaded it yet as it is unplayably fast, it gets to the bottom in 3-4 seconds.

I'm not actually short of CPU power in this project, I think it spends 80% of its time in IT (wait for timeout), what I am short of is memory. Nine games is a lot for 2k.

Monday 16 October 2017

Over the weekend - second half

Today : eating Pizza rather than writing code.
.... didn't get anything much done at all. I have tweak
ed the source code a bit, and also added a mechanism by which games can be selected by clicking on a simple menu in HTML.

This gets round the cartridge swapping thing because there aren't any cartridges.

By my reckoning I have six games and 15 days, which is a couple of days per game.

The next games will be (probably) Space Invaders, Dodge Em and Road Runner. These are all doable reasonably quickly.  This leaves the three that concern me a little timewise, Basketball, Football and Sea Wars.

We shall see :)

Thursday 12 October 2017

Game#1 Asteroids

Game in Progress ....
So Game#1 is up. It's a very simple game where you have to dodge the falling rocks, in your Space Shuttle.

All the system stuff works - you can set the speed, 1 or 2 players and it will alternate them. When your turn is over it shows you the other hologram (a pic of the Shuttle, holo#1 you can see here, some rocks and a surface).

Games apparently either did this, or they had left/right sides for the sports game and the sea war game.

I've also fixed a couple of bugs (holograms weren't switching in this JS port ... they aren't holograms ... because I'd forgotten to write that bit of code) and rewritten the code for generating back lit holograms, which just didn't work in practice.

I'm beginning to see the limitations of this unit. I'm not convinced that however good a programmer you are - and Atari at that time had some very very good ones - it's possible to squeeze 7 decent LED games into 2k.  Things like Mattel Football were 2k in their own right. Even Simon, a much simpler game, is 1k.

Wednesday 11 October 2017

A sort of game ....

it really is just a test for my pixel collision routine which I've just written.

It is the basis of a game, it's just not very hard, you can't fight back. You can just shoot the baddies (with the completely inappropriate hologram) and get a point each time you do it.

Still next up is the first proper game, which will be Asteroids, or really a simpler version of the Intellivision Astrosmash.

I did get Asteroids in 64x32 on a Studio2, but 7 x 6 resolution .... nope.

Studio II Asteroids

The code hasn't changed much, basically MovePlayerMissile skips if the missile is in flight - if you need to check collisions. It calls the new CheckCollision function, which skips itself if there is a collision, with the pixel ID in A + B. This object is killed, the PlayerMissile is killed, the score is bumped and round we go again.

I realised why the NOPs are there ; it's a feature of MoveUp/Down/Left/Right which the MoveXPlayer routines use.  I think I'll leave it.

    jsrp     Update
    jsrp     MoveHPlayer
    nop
    jsrp     MoveVPlayer
    nop

    jsrp     CheckFire
    jsrp     MovePlayerMissile
    jp         game_code

    lbi     0,PlayerMissile
    jsrp     CheckCollision
    jp         game_code

    jsrp     Kill
    jsrp    KillPlayerMissile   
    jsrp     BumpCounter
    jp         game_code

More general routines

The plan is to write most of the general routines which can be reused up front, then do the actual games.

Some of it now works. If you run the latest version, of the Javascript version (link on right) or the C version you can now move your "player" LED with the arrow keys and shoot a "missile" LED with fire (Control key).

A Cop444 has a JSRP instruction which does a subroutine jump into page 2; what I'm doing is creating a whole pile of extra one byte instructions that do far more complex things.

So, in this bit of code there's the following which does this.

Update updates the screen display, timers and scans the keypad.

MoveHPlayer/MoveVPlayer move the player in that axis. They both skip if you move off the screen hence the NOPs. (I might change this as none of the games need this). CheckFire fires a new missile if possible and the fire key is down. MovePlayerMissile moves the P/M if it is in flight and return-skips if it is still in flight (e.g. you might check it collides with something). In this demo it increments the counter when the missile is in flight. (BumpCounter .... increments the counter)

All of these instructions are one byte JSRP commands.
game_code:

    jsrp     Update
    jsrp     MoveHPlayer
    nop
    jsrp     MoveVPlayer
    nop

    jsrp     CheckFire
    jsrp     MovePlayerMissile
    jp        game_code

    jsrp     BumpCounter
    jp       game_code

Tuesday 10 October 2017

It lives :)

The Javascript Cosmos is now alive and it lives at http://www.studio2.org.uk/cosmos/

Keys are : arrow keys for directions, P for player, S for skill level, ENTER to start and CTRL to fire.

At the moment all you can do is to select the player number and skill level with P and S and start it. When this happens, the LEDs on the top row light sequentially and the left 7 Segment LED counts.

The app needs to have the focus so it may need clicking on before it will work.

But this is exactly what the C one does :)

I will try to keep this up to date so when some games appear they can be played on the JS version or the C version.

Obviously it is much easier to play games on the JS version but it's easier to develop on the C version ; the JS version has no debugger.


Monday 9 October 2017

Getting there

To go with a mostly working CPU core - a mostly working display :)

Maybe working tomorrow .....

Javascript Port

Thinking about actually running it, I've decided to port the emulator to Javascript, well actually Typescript which I rather like despite its Microsoft origins.

Having been developing stuff with MS since Windows 3.0 one gets paranoid about embrace, extend, exterminate. Or just being dumped. Some of us remember when the web was all going to be ActiveX web apps written in Visual Basic. Or Silverlight. But this does appear to be genuinely open source.

Phaser will do the graphics and sound and so on.

I modified the COP444 code generator slightly to suit JS code generation as well as C, and got it generating a typescript file which is a superclass of an abstract processor class which is itself then subclassed to add useful and necessary stuff.  Each opcode becomes a function called opcode_207() or whatever and an array of these functions is returned by an accessor method. I'm unconvinced by javascripts case statement, perhaps unfairly. The one thing about GCC is you know it's going to optimise the case to a jump table.

Mostly these changes involved getting it to output things like this.a rather than A in code ; JS and C are near enough syntactically and the output code simple enough that it's pretty much all just replace().

It seems to be working even though there's no real hardware ; it is just a dummy class which implements IHardware and outputs what the CPUs doing to it, but running the "ROM image" it is certainly doing the first bits - figuring out the Game ID, displaying S1 on the LEDs and then scanning the keyboard.

The next time I write a framework emulator I'll probably think through a JS port in advance.

Sunday 8 October 2017

Core Mostly Done

Apart from utility routines, of which there will be several - move, collide etc. I've done a fair amount, pretty much all of the core.

First thing was a replacement of the timing system with a lot more flexible one that allows a lot more choice in speeds, but keeps the basic idea - that the timers go quickly in slow mode.

Then the select phase has been added ; when you start up it displays S 1 on the 7 segment displays and the #players and skill switches change this to S 2 F 1 or F2. Start then starts the game.

As I wrote yesterday there's a sort of very very slow task switcher in there ; whenever the player changes it swaps pages 0-2 and 5-7 round (page 3 is stuff like keys and timers), and when both tasks are killed the game is over. I initialise it by creating both anyway and killing a player for the one player game.

This then goes into a jump table using the JQID instruction, which goes to the entry point. If the carry is set it initialises the game and returns, if it is clear it plays another round of the game.

At the moment all I have is a 'game' which counts on one of the 7 segment LEDs and moves a lit led across the top row, but it works well enough to get the core tested.

Next up, some games. At the moment I'm using 4 1/2 pages of the 32, which leaves 27 1/2 or a bit less than 4 each. Should be enough for most, though I'm a bit worried about the football / basketball games especially. I suspect these are simpler than the Mattel games.

Saturday 7 October 2017

Minor improvements

I've been running Arch Linux for a while and yesterday they transitioned to Gnome 3.26. For some reason I couldn't figure out, SDL2 no longer worked, it crashed the Desktop Environment, may be something to do with Wayland changes maybe.

Anyway, I've been thinking of changing for a while, so my spare time yesterday was spent shifting to Fedora 26, which works fine and is surprisingly quick.

So everything is working again. But I haven't written much code since yesterday because of that, the code to keep the overall synchronisation going and a routine to exchange the contents of pages 3 and 4 of RAM.

I have a 'sort of' game. Actually all it does is increment one of the timers and shift a pixel, but it still has an 'init' and 'update' part which is all I want for testing. I will use this "game" to write the code that handles the selection of speed and #players - I'm presuming here that this is selected by the two buttons and pressing START starts the game and subsequently handles the toggling between the two games. All games will be turn taking. Exactly how I multitask this I'm still considering .... rather than just switching 3 and 4, the original idea, it might be advantageous to switch banks 0 and 1 as well, make bank 2 the 'local data' page and switch that, and bank 3 becomes the common page (game ID, speed, player#, keyboard status, counter status and so on), then switch banks 0,1 and 2.

At this point making those changes creates no problems, but it needs some thought.

Friday 6 October 2017

Hardware Interface

I've been working on more general interface code. You can see it running here.

The first two pages 0x and 1x are the 'on LEDs' - only one at 08/18 at 4,B which is 4 across, 4 down. 0D/1D and 0E/1E are set up to access LEDs (E and F values) and re displaying digits 60 (2D/2E)

New stuff includes the game ID, which is at 2C at the moment ; this is the 'cartridge selector' connections which are currently %0101 or 5.

The keyboard scanner also works - this is at 20-24. Bit 3 of $20 being set means the left key is being pressed, Bit 2 of $21 means that the 'Number of Players' key (P) is being pressed. If fire was being pressed bit 0 of $22 would be set.

There is also code to clear the screen and the whole of memory.

I'm going to have 2 players by having the 'current player information' in $30-$3F, and switching this with another bank, $40-$4F maybe,  each time the player changes sides. Additionally the difficulty level will be primarily speed based. With a bit of luck all this will be automatic.

Thursday 5 October 2017

Some actual working COP444 code.

In the end after some tinkering I decided on the following for video generation.

Page 0 of RAM, from 0-14 is used for the x coordinate which can be zero (off) or 1-7. Page 1 of RAM from 0-14 is used for the y coordinate which is from 8-15 representing row 0-5 on the LEDs, the left 7 segment and the right 7 segment.

If a Y coordinate in page 1 is 14 or 15 (the 7 segment displays) then the digit is taken from the equivalent row in page 2.

The code is shown below (minus the data tables). The handy thing about the datatables is if my assumptions are wrong about how the wiring works, all I have to do is change the datatables.

I originally thought that the layout had to be sensible (e.g. the 7 LEDs being G2 G1 G0 D3 D2 D1 D0 in order) but with this system it doesn't matter. Though it probably is still that way.

This routine doesn't quite fit in a page with the three tables (column bit, row bit, 7 segment lookup) unfortunately and I can't make it fit, it's about 8 bytes too long.

One perhaps rather optimistic question ; does anyone know if the COP444's IT instruction resets the timeout flag. IT is 'stop processor till timeout' - a COP444 has a 10 bit internal timer but it isn't clear whether this resets the timeout overflow flag or not. SKT definitely does, but of course skips ... because the timer has overflowed. If IT does reset the flag I can reduce the IT/SKT/NOP sequence to just IT.

This synchronises the timing ;  one LED is displayed every timeout, this routine takes the same amount of time (16 timer cycles, a frame rate of about 16Hz) when it is called, irrespective of how many LEDs are displayed (this allows a maximum of 15 or 13 + 2 score digits)

I do wonder if this will be a bit like Microvision Space Invaders. That was on a TMS1100 , a very similar processor with 2k of ROM space. I was a bit panicky about space when I started it and wrote tight but unclear code (the code below has two seperately overlapping loops), but I ended up with half the ROM space unused.

We shall see. I should be able to write tighter code than the original developers if for no other reason than I have much better development tools - I can reassemble in a second, I have a proper single stepping debugger. I don't doubt the original developers were awesome programmers.

I suspect the original devs had a much slower turnaround, which means you program more defensively. A defensive simpler version of this is about half as long again.

It's amazing what you do in retrospect. When I was a kid I had a Sharp MZ80K, which had BASIC loaded from tape. If you crashed it, you reloaded the tape which took 3 or 4 minutes. I hacked the BASIC to add a pile of commands including a complete Z80 assembler that worked like the one in the BBC Micro. Still not quite sure how :)

__Repaint:
    lbi     1,15                            ; point to first one plus 1, also set B upper to one.

RPDoneY:
    ld      1                               ; switch back to zero.

    it                                      ; delay for brightness
    skt
    nop

    cba                                     ; get the pointer.
    aisc    15                              ; effectively subtract 1 and skip on not borrow
    ret                                     ; borrowed, so return.

RPContinue:
    cab                                     ; save new address in B.
    xad     RowTemp                         ; save it in RowTemp

    clra                                    ; A:M now points to the table in the first 16 bytes.
    lqid                                    ; read the 8 bit pattern into Q.
    skmbz   3                               ; if M(B) is in range 0-7 it is 'X', so skip.
    jp      RPDoneY                         ; otherwise we have done Y, so complete.

    ld      1                               ; point to Y
    smb     3                               ; set the mandatory bit 3.

    ld      3                               ; read Y this value is 8-15. Execute if 14,15. Set Bu to 2
    aisc    2                               ; will skip if 14,15
    jp      RPNotSevenSegment 

    clra                                    ; read from seven segment table.
    aisc    15
    lqid

RPNotSevenSegment:
    ldd     HoloDisplay                     ; read the holo display location
    aisc    15                              ; set carry if non zero
    nop

    lbi     RPWork1                         ; point to useable location for CQMA and set to page 1.
    cqma                                    ; copy X 8 bit data to MA

    smb     3                               ; set bit 3 if carry set.
    skc
    rmb     3                               ; otherwise, clear it.

    omg                                     ; output high 3 bits and G3 bit set here.
    cab                                     ; output low 4 bits 
    obd

    ldd     RowTemp                         ; load rowtemp, Bu is still 1
    cab
    jp      RPContinue                      ; and do the Y part

Wednesday 4 October 2017

Thinking about games & core routines

I've spent some time thinking about how the games actually work, and as a consequence of this how the core routines should operate.

I am working on the premise that the games are like other games of the same name, where practical, looking at Atari hardware, 2600 games and similar LED games.

There is some description of games in the Atari Cosmos Patent (4,421,317), (though annoyingly its mostly about the hologram technology( and a bit more in the interview with Roger Hector.

I'm thinking along the following lines.

Basketball, Football and Space Invaders - Atari don't seem to have done LED versions of these, so these will use the Mattel games and Entex game respectively for ideas.

Asteroids - there are very few LED Asteroid games - unsurprisingly as its a vector graphic game, so I think this is more like the Intellivision game Astrosmash (the one LED game I could find was like this) e.g. Asteroids drop vertically and you shoot them.

Dodge'Em - a classic game where you have concentric squares in a maze and you go round dodging the bad guys. Presumably a similar game to the 2600 games.

Outlaw - a game where you shoot at each other - a gunfighter simulation, this too has a 2600 equivalent.

Road Runner - I can only find a 2600 game and a Tiger LCD game, this appears to be a sideways scrolling dodge and collect game.

Sea Battle - probably the best described game of the lot, as it is described in the Patent and by Roger Hector. However, not much actual mechanics information.

Superman - an original game based around collecting dragons.

Originally, I was going to do this as a "memory mapped screen", where there is an area of memory where bits are 1 and 0 for LEDs being on and off. This works fine, but having tried it and though about it it lacks a lot of flexibility.

So plan B is to have a list of LEDs that are turned on. These can be moved about by changing the coordinates which are stored in adjacent lists - so say making a bullet go up involves subtracting one from its vertical position and it 'automatically redraws' rather than bit twiddling memory which 4 bit processors aren't great at.

The "odd one out" is DodgeEm which has a "Pacman" sort of system - a maze where you collect the Dots. I might work round this by doing what Magnavox did with their Odyssey II Pacmans - having enough dots so you have to go round the whole maze, but not so many that it can handle the numbers. Or maybe I'll just do an overlay. To be decided :)

Tuesday 3 October 2017

and some .... sort of ...holograms

This is the cross between the last two posts. It's using the hologram image and the LED cycling program to produce a sort of hologram with LEDs display.

Obviously needs a bit of fine tuning ; it looks a bit too blocky, might reduce the difference between the dark and the light graphics, as the hologram is independently lit anyway.

It's a bit primitive, but it works. I can also switch between the two holograms and have the keyboard hardware emulated.

Monday 2 October 2017

Working emulator

So, I now have a semi working (only a couple of bugs found so far) emulator of the processor and the display.

Most of the code has been borrowed from earlier emulators I wrote - I have a framework where you just provide the debugger display and the runtime and it does everything else pretty much.

There isn't that much difference between a COP444, an SM510 and a TMS1100. Though I maintain the SM510 is broken as a processor because it can't do an indirect write ; this stuffed up a previous Retrochallenge.

The code it is running is writing patterns to the display, it's rubbish code but just slung together to make it work. This is on the left at the top. Registers and I/O ports are in the middle, and the display is on the right - a pair of 7 Segment LEDs and a 7x6 LED array.  The bottom chunk is the COP444's 128 nibbles of RAM.

I want to replace this display with bits cut from the "hologram" images shown in the last post ; this will require some hacking of the Framework so that it can read in and render PNG files, which it can't do at present.


Sunday 1 October 2017

Rendering Holograms.

The 'video' display of a Cosmos is an array of 7 x 6 LEDs with a switchable 3D hologram in front of it which can display one of two images.

The hologram is like those things you used to get with breakfast cereal (if you're my sort of age) where it displayed two seperate images depending on how you tilted it.  I don't remember if any of these were 3D OTOMH.

A Cosmos doesn't tilt it, it just shines light on it from different directions, and from the LEDs behind.

Going to have some issues with 3D, so I've flattened it to 2D.

I've written a Python script which takes the picture (the flowers and the UFO, first things off openclipart.org ....) and produces two versions of it ; one is darker than normal because there's no background LED, and one lit by an array of 7x6 LEDs (the green bar is solid colour so doesn't show the Red directly). The colours of the objects are reddened slightly as well so it looks like RED LEDs are lighting it up - so the flowers look pinker on the top.

The emulator will just grab a square chunk of the graphic depending on what LEDs are on and which Hologram is selected - there will be two of these image - pairs as each hologram can display two different images.

At the moment the prototype emulator just displays a grid of square LEDs. If I build a real one - I have the parts for this, a 16x8 LED array (half for the digit display), a Mega2560 and a joypad shield in my bits box somewhere.

Git Repository up

At https://github.com/paulscottrobson/atari-cosmos

Saturday 30 September 2017

Assembler

I've written a Python assembler for the COP444. I think there might be one in Alfred Arnold's AS assembler, but it's not clear, and anyway it's not very long winded and it's harder to hack it the way I want.

It's a one pass back-wiring assembler, which means that it just saves all the Jump and Call routines and patches them back in at the end when all the labels are defined.

It's mostly fairly straightforward though the Jumps and Calls are a bit peculiar. Outside $80-$FF the opcodes $80-$FE are jump in page, and call in page 2 - so very regular calls can be reduced to a single byte opcode, but in that range it is a jump within pages 2 + 3.  Like most 4 bit microcontrollers it works in 64 byte pages, though unlike many it does allow code to just run from one page to another. A TMS1000 only has a 6 bit program counter and a 4 bit latch, rather than a full 10 bit program counter.

I've also started on an emulator for the COP444 ; this again is fairly straightforward apart from this Jump/Call peculiarity.  Hopefully in a couple of days there will be some actual working code up.

Thursday 21 September 2017

The Keypad.

So, as far as is possible from the available information, I've got a fair idea how the display, game select and sound works.

We're left with the keypad. We have three unused input lines IN1,2 and 3 and several output lines.

So obviously there's going to be some sort of matrix using the input lines ?

Well, nope, there isn't. If you look at the PCB you will see the IN 0 1 2 and 3 tracks. They are the 5th and 6th from the left. IN0 , which is the 5th from the left on the top, is connected to the display connector and a pull down resistor.

The other three form a "mini bus" of three lines, which head up the right side of the board - you can see them between the two connections of the ground line for the display connector, to the right of "REV 0 3".

This had me baffled for a while. There's a connector up there, which looks to be about four pins, which isn't used for anything. The keyboard connector is the seven pin one roughly dead centre, this is below the MCU chip. If those lines ended up there you'd see it on the component side.

What I noticed when reading the COP444 database is this chip has two serial interfaces. The second one is called "Microbus" and uses the IN1,2 and 3 lines. In this mode these become the strobe lines and data is passed in and out using the L-lines. I'm guessing here, that this is some sort of debugging, or testing system, or even maybe an expansion system ?

This still leaves us with the inputs. By a process of elimination, the only thing that the keyboard can be connected to is L ; D + G just aren't available electronically - physically on the PCB. L is handily placed and there are some resistors which look like they might handily connect to the keyboard connector (more obviously in the prototype).

There is a problem though. L lines are either inputs or outputs, but they are all inputs or outputs - so INL (input L) appears to switch everything to inputs. To put a matrix keypad on L we need some inputs and some outputs.

The trick is I think that it is possible to use the outputs as pullups for the inputs, but only if you use the Low current Tri-State "L" output (type e). The output types are set at ordering time.

EN2 needs to be set and importantly the Q latch lines need to be set to logic '1'. So I think these are controlled individually - the pull ups are connected through a matrix to high impedance inputs  which are a type of output that doesn't operate as a pull up so it reads the pull up or pull down, depending on the connections through the matrix, this gives us a 4x4 matrix, which we can read by only putting one pull up on. The resistors may well provide a pull down for the lines where the pull ups are not activated, but a pull up will override a pull down voltage level wise ; it is a sort of output.

There are seven connectors on the keyboard cable. There are four directions, numbered 1-4 a fire button, a skill button and a 1/2 player button.

There appear to be no diodes, so the usual keypad problem of pressing 2 keys at once can create spurious inputs will occur.

I'm presuming therefore that there are four seperate input lines for 1-4 which take up one pull up line, three seperate lines for start, skill, and 1/2 player detected by a second and one on its own for fire. Because fire is the only button connected to an input, it operates independently.



So , completely arbitrarily really (mapping 1-4 onto bits 0..3 is kinda logical), but the rest .... well it's an educated guess.

L7 set to pull up

Key 1 (Up) : L0
Key 2 (Right) : L1
Key 3 (Down) : L2
Key 4 (Left) : L3

L6 set to pull up

Start : L0
Skill : L1
Players : L2

L5 set to pull up

Fire : L0

Wednesday 20 September 2017

Selecting the game

Top and Bottom PCB, low resolution, probably final version
The Atari Cosmos actually has all the games built into it, so a method is required of actually selecting which game to play. The solution is on the top left of the display board, shown here on the left, the five pads are contact pads for wiring on the "cartridge" - which is actually just the holographic dual image in some kind of box.

There are four potential Input lines IN0..IN3 remaining on. If you look at the PCB picture from the last post you will see the fifth from the left on top goes up to the display connector via a resistor - this is the far left connection on the display connector on the PCB track side. This is pin 19, IN0. I conclude this line is the game selector feedback and there are four outputs, each of which are interrogated in turn by raising an output line. If a signal comes back in IN0 that pad is connected, giving us a 4 bit binary number.

It is probable, no more, that this is the D line, because there are 4 D bits going to the display card and 3 bits on the G line, it's easier again on code space. It is possible that one line is 'on' when a cartridge is plugged in and the other three game select. In which case it might well be 3 G and one D line, who knows.

Of course, without either cartridges or a ROM dump there is no way of figuring out which game is which bit pattern, but we'll get round this with equates or something.

Tuesday 19 September 2017

The display interface

Note : if anyone reads this and thinks I've done something obviously wrong, please tell me - I'm not really an electronics guy.
Atari Cosmos PCB, track side
This is probably the single most useful image I have. It not only shows some of the connections and wiring but gives hints as to others. This is a single layer single sided PCB, so tracks must go in the direction of things that use them - or there needs to be a corresponding wire on the top side of the PCB.

COP444 Pinout
So, the first and most obvious thing is this is the flipside of the COP444. It's pinout is on the left (hopefully ....).  Bearing in mind it is upside down - e.g pin 1 is the lower right pin (you can see the 1) we can see the lines D0-D3 and G0-G3 on the top right of this PCB.

Seven of them, representing the seven columns (or seven segments) are connected to resistors (that go over the ATARI INC label) and straight into the Display Connector.

It is highly likely that these are the connectors to the display columns (think of it as a 7x6 array + the 7 segment displays). Nothing else makes sense.

I don't know how the wiring is done, but for the sake of programming sanity it is likely to be G2 G1 G0 D3 D2 D1 D0. It might not be - sometimes designs are done for ease of wiring and it's sorted out in the software - but there are so many complex wires in the display board it doesn't seem like it would matter and when you are cramming 8 games into 2k of 4 bit code then that's your low resource.

G3 is not connected in the same way - this is the track that heads off to the top left corner for a bit, and I think, connects to the track between the words www and atari (I must give references for these pics), after which it heads off left.

This, I think has to be the line that selects which of the two holographic displays to be used (the Cosmos has an overlay for the LEDs and can programmatically display one or the other). It's off in the right direction, and it is not the same functionality as the other G and D ports.


On the bottom side, mostly are the L-lines. These are bidirectional I/O lines. The
LED Driver circuitry using transistors
first two L0 and L1 which are the two most extreme left pins are connected to 0V via pull down resistors. The rest of the L lines seem to head off left and top left.  This direction, and some resistors, and the fact that there are conveniently 8 of them, suggests that these are the row drivers - there are 6 rows plus two seven segment displays. There are 8 transistors in the top right of the board (looking at the component side) and resistors and transistors that suggest this arrangement shown on the right (hopefully) where A0-A6 are G + D and B0-B7 are L0-L7.  Again, I do not know which row or display is connected to which L-line.  I am working on the principle that the 6 LED Rows are L0-L5, L6 is the left digit and L7 the right digit, and the segments are in standard form, but actually this doesn't matter as it'll be driven from two lookup tables.

This doesn't leave much. The two clock inputs, RESET, the power lines,  the four input lines IN0-3 and the Serial I/O connections to the Sound Microcontroller. (SK SO SI).

There's two outstanding issues. First is the game selector , and second is the keypad layout. This latter is, well .... interesting.

Irrelevancy: The COP444 has an "OMG" instruction, which is coincidential (it's too old) - it outputs a Memory Nibble to the G port, which belongs with HCF and SEX. I'm sure they weren't accidents :-)

Monday 18 September 2017

Hardware Introduction


A nice pic of a disassembled prototype / development Cosmos. I'm going to run through the hardware in outline and then do a bit more detail .... what I think is the detail anyway.

Some of it I just don't know at all, without being psychic, but much of it can be deduced to the extent where you can code for it if you use constants in the assembler code. (Except for the sound ... other than it uses the serial interface I have no idea how it works at all)

As an example, it's impossible to deduce which bits are up down left right on the keyboard without either a ROM dump (and nobody's going to do this !) or access to the PCB and a multimeter (and they're not going to do that either). I sacrificed a cartridge for the Microvision archiving effort (you have to destroy them) but with Cosmos systems going into 5 figures .... not going to happen.

Sometimes this is ropey. I have occasionally made deductions on other machines based on the concept that the designers weren't idiots, and sometimes they've been ... idiots. However, there are some top brains behind this machine, so I suspect it is intelligently designed. Assuming this helps :)

I do have some close ups of bits of the PCB. It is single sided which is quite handy, because you can deduce some things from the single-sidedness - if a signal can't get to the keyboard connector, it can't actually be part of the keyboard circuitry.

The processor. Now virtually everything on the Cosmos gets this wrong ; it isn't a COP411, it's a COP444. You can see it left/centre on the main circuit board with the gold square. It's a 28 pin chip, and a COP411 is a 24 pin chip. The close ups also have "COP444" on it ;-)

I'm not surprised because even a COP444 only has 2k of ROM built in and you have to fit 7 or 8 games (can't remember) into that. Even at a low level of complexity that's not easy.

There is actually a COP411 on the board though. You can't see it in this picture (it's underneath the orange toggle switches on the right/centre. It's an arrangement like the Entex Adventurevision, the little MCU generates sound effects. The two are connected by a protocol "Microwire" which uses the Serial I/O pins on the processors.

Just below the processor, in the middle, is a 7 pin connector that loops round via the ribbon cable and connects to the keypad on the front of the unit.

Below that is the Power Supply unit (most of the left hand side, (and presumably the two capacitors !), and there's a plug on the lower right (which is soldered here but is another connector on the production board) which is connections for the odds and sods - speaker, image selector.

Immediately above the main MCU there is a seven resistor array which connects directly to the display connector (it's the red thing you can just see peeking out from the bottom corner of the display board) and on the top right of the circuit board are the current drivers for the rows. There's 7 across and 8 down (actually 6 down and two seven segment displays).

The thing with the LEDs is the display board, with its 7 x 6 grid and two 7 segment displays (the white box). Directly above this you can see 5 circular pads. These are the contacts for the "cartridges" (actually just the holographic images). Connecting one or more of these pads to the input line (probably the rightmost) selects the game to play - the games are already built into the processor.

This is the purpose of the orange toggle switches - they are a development hack so you can 'select a game' (e.g. connect the pads to the input) without actually having to have different cartridges ; the push button is probably connected to Reset.

The connector is the 16 way ribbon cable that goes round the back of the PCB and plugs into the just visible display connector.

On the right hand side, the grey box is - maybe - the hardware for selecting the 3D Holographic image - the Cosmos can display one of two images. These vary - sometimes it's a game and a game over screen, sometimes it's two ends of a football field.

Below that, obviously, is the speaker.

The other connector that you can't see is a little one immediately above the display connector. This one had me baffled for ages..... more on that later.

Saturday 9 September 2017

Introduction.

This is my Retrochallenge for October 2017 ; to try and recreate a version of the Atari Cosmos. The picture is of a dismantled ones.

There is not a great deal of information available about this console to put it mildly, and there isn't likely to be anything like a ROM Dump, because there are something like 5 of them in the world, only 2 of which have actual electronic bits in them.

The going rate on eBay was something like £20,000 ..... so I can't see anyone handing over a COP444 so Sean or Kevtris can decap it. If I'm lucky I might get a high res scan of the main board (I have a highish res scan of the bit around the MCU which is quite useful)

It comes from the LED games era - the screen resolution is 7 across by 6 down, the unusual feature of this machine is that it had a holographic display which was superimposed on the LEDs.