Atom Colour Board Thread

[jgharston]

Doing a bit of tidying up of my Atom, System and SA5050 documents, a thought occured to me. Did anybody ever create a teletext display adapter for the Atom? Nice, crisp, 40-column 8-colour text. The Atom's default screen is already a character-mapped display, so it would only be minor changes to the VDU code.

[Prime]

Doing a bit of tidying up of my Atom, System and SA5050 documents, a thought occured to me. Did anybody ever create a teletext display adapter for the Atom? Nice, crisp, 40-column 8-colour text. The Atom's default screen is already a character-mapped display, so it would only be minor changes to the VDU code.

I seem to remember that the code to drive the System's 40 column board was included in the AtomDOS rom that was on the Atom disk pack interface.
The Idea was I guess that since the Atom & System used the same bus pinout you could just use a System board.

Cheers.

Phill.

[oss003]

Doing a bit of tidying up of my Atom, System and SA5050 documents, a thought occured to me. Did anybody ever create a teletext display adapter for the Atom? Nice, crisp, 40-column 8-colour text. The Atom's default screen is already a character-mapped display, so it would only be minor changes to the VDU code.

The 40 column software is in the DOS rom and can be started with a *VDU command IIRC.

Greetings
Kees

[Prime]

Dammit!

I've blown another CPLD. I'm pretty sure this is down to transients on the SCART cable, I've re-wired the cable and heatshrunk all the connections to try and prevent shorts. But in the long run I'd rather have the board as able to withstand shorts as possible.

So can anyone see anything I can do to try and mitigate this?

This is the current schematic (for the next version of the board). One thing I thought might help is to include a 74LS type buffer between the CPLD outputs and the transistor inputs, something like either an LS04 or an LS245 (obviously perminently enabled and with DIR pulled as needed).

AtomColour.pdf

AtomColour 5.7 schematics

(143.62 KiB) Downloaded 142 times

Cheers.

Phill.

[Multiwizard]

Doing a bit of tidying up of my Atom, System and SA5050 documents, a thought occured to me. Did anybody ever create a teletext display adapter for the Atom? Nice, crisp, 40-column 8-colour text. The Atom's default screen is already a character-mapped display, so it would only be minor changes to the VDU code.

Hi Jonathan,

you all know I'm not the smartest, but from time to time I have some nice ideas or solutions...

So just an idea...

The last few years since Roland had designed the Acorn Atom BBC HW Expantion Board I'm asking myself if it is possible to connect a Beeb Teletext cheese wedge (through the board) to a Atom and get it working...

viewtopic.php?f=44&t=12214#p170236

Like I said, just a thought...


Greetings, Wim...

[jgharston]

Doing a bit of tidying up of my Atom, System and SA5050 documents, a thought occured to me. Did anybody ever create a teletext display adapter for the Atom? Nice, crisp, 40-column 8-colour text. The Atom's default screen is already a character-mapped display, so it would only be minor changes to the VDU code.

The 40 column software is in the DOS rom and can be started with a *VDU command IIRC.

Ah! That rings a bell.

[1024MAK]

I've blown another CPLD. I'm pretty sure this is down to transients on the SCART cable, I've re-wired the cable and heatshrunk all the connections to try and prevent shorts. But in the long run I'd rather have the board as able to withstand shorts as possible.

So can anyone see anything I can do to try and mitigate this?

One thing I thought might help is to include a 74LS type buffer between the CPLD outputs and the transistor inputs, something like either an LS04 or an LS245 (obviously perminently enabled and with DIR pulled as needed).

Hi Phill

Yes, it is worthwhile including a buffer chip (in a socket).

Also note that Sinclair QL’s suffered damage due to the RGB monitor sockets. Thought to be due to users connecting or disconnecting the lead while the computer and/or the monitor were still switched on.

I would also consider adding some low value resistors (between 10 ohms and 150 ohms) in series with the output transistors. Either in the collector circuit, or the emitter circuit to limit the current flow in the event of a short or a transient.

You may also want to include some filter components between the main 5V Vcc supply and the 5V Vcc supply used for the video outputs in case transients are back feeding this way. So say a 10 ohm resistor and a low value choke with suitable 100uF and 100nF capacitors either side of the series resistor/choke.

One further thing. Class II consumer appliances like televisions often sit at a DC voltage (relative to earth) that is around half the mains voltage, with a significant AC component. This is due to the Y class suppression capacitors. It can create quite a spark (often only visible in the dark) when you connect another device that is at a different voltage potential (whether earthed or not). So you could fit fast switching diodes to the outputs (connect one diode from 0V to the output and one diode from the output to the +5V Vcc line) try to clamp any such voltage spikes. A 5.6V Zener diode should also be connected across the +5V Vcc supply.

Not sure how effective any of this would be though.

Mark

[jms2]

Phill,

I know you were never able to reproduce the screen rolling instability problem with version 5.1, but is there reason to believe that the new version 5.4 might perform better in that regard?

Well, I was able to reproduce the problem with "Cowboy shoot out", this board doesn't seem to have it. The difference.....there will be two resistors soldered to the back of the Mk5.1 board, they will be either 22R or 33R (I think). On the 5.3 I replaced them with 470R, and on the 5.4 with 270R, both of those values seem to help cure the cowboy shootout problem at least for me. So that may be worth trying.

Cheers.

Phill.

Hi Phill

As a first step I have tried replacing the 33R resistors on my v5.1 board with 270Rs. However it doesn't seem to make any difference. I have got a different LCD TV to use with the Atom now (a Panasonic 15") but it's no better than the Samsung I tried previously. With Cowboy Shootout there are three "modes" - not rolling at all on the static death screen, rolling a bit in the game normally, and then if the rolling gets completely out of hand my TV switches to a grey screen.

What I can't remember (and need to check) is what variant of the firmware I left loaded into it. I was experimenting with different VS sync pulse widths, which had slight effects but didn't seem to help much. Ideally I need to revert back to whatever you originally supplied to validate whether the resistors are helping. And/or I could go up to 470R.

Possibly unrelated, there does seem to be a warming up issue affecting some aspect of my Atom (don't know if it is the colour board or not). When I first switch on I don't get the common Atom "screenful of garbage characters", instead what I see is a steady (non rolling) picture comprised of a kind of green and black checkerboard. There is no rolling, but sometimes the horizontal bars are expanding in height, sometimes they are steady - it's certainly a TV picture artefact rather than something coming from the Atom itself.

Then after about 3 minutes a get the usual black screen with "ACORN ATOM", but a block cursor and no prompt. If I press Break a few times I finally get "ACORN ATOM + ATOMMC2" and a proper prompt. After that the machine is fine, even after unplugging and switching on again.

[Prime]

I've done some more investigating on the vsync issue.....

No longer seeing it in "Cowboy shootout" but I am seeing it in Acornsoft "Invaders", oddly only when it's in mode 4, and moving the invaders on the screen. Now simultaniously with doing this it will be reading the keyboard and producing sound all of which access the 8255. So I'm going to investigate exactly *WHAT* it is doing to try and see what might be the problem....

I have rigged the CPLD to output the VS pulse on it's own on a spare pin, scoping that and FS and it seems to be in the correct part of FS but sometimes seems to get missed, which is odd, this is I think where the display jumps.

Cheers.

Phill.

[jms2]

I think that is definitely an interesting avenue to explore because it is clear that software is having a crucial influence on whether the display jumps or not. It isn’t anything to do with how “demanding” a game is in the usual sense, but I can well imagine that even a run of the mill game like Cowboy Shootout might be taxing to the 8255. Although why that matters is not clear to me - does the 8255 affect the 6847 timings somehow?

I’ve made some progress with the boot up problems on my Atom. I found that pressing on the right hand side of the PCB next to the speaker causes it to crash, or alternatively to boot properly if it wasn’t doing. On the component side is one of the last remaining dreaded white sockets... so that has got to come out!

[Prime]

jms2, What RAM chip is on your Colour board?

Just found something interesting playing with the new version.......

With a CY62256 55ns 32K RAM on there I get the problem of the sync jumping about.
With a 6264 made by RCA, I think it was harvested off a Slogger Turbo board....thanks Arcadian It's absolutely rock solid stable, I'm not sure why.

It could be the higher switching speed of the more modern chip is causing problems, but the chip is decoupled with a standard 100nf right next to it's VCC pin.

So it looks like the faster modern chips could be problematic in this application. Wonder where I can get some of the older slower ones from, after all the board only needs an 8K chip, I was only using the 32K as they where cheaper.....

The other odd thing I found, was that I was testing using Kees' Manic Miner port, and on screens where the enemies where mostly moving horizontally there was very little disturbance. But on screens where they where moving vertically the disturbance was much worse. I guess this could be realted to the fact that horizontal movement will me moving memory in the same small region, as addresses increment across the screen. But vertical movement translates to a larger range of addresses accessed.

Acorn "Invaders" though seemed to cause the glitch all the time (whilst in graphics mode), I guess even though the movement is mostly horizontal it's a large vertical area of the screen that is moving.....

Cheers.

Phill.

[jms2]

It's an intriguing theory, but I think this might undermine it a bit...

...mine is an NEC D4364C-15L.

I might have a different (old) 4364 recovered from my old black and white video card.

[hoglet]

With a CY62256 55ns 32K RAM on there I get the problem of the sync jumping about.
With a 6264 made by RCA, I think it was harvested off a Slogger Turbo board....thanks Arcadian It's absolutely rock solid stable, I'm not sure why.

I wonder if you are getting brief periods of bus conflict between the RAM and IC29 (the 8304 buffer).

Looking at your schematic, the RAM is enabled all the time.

Let me have a think about the signal timing and see if I think this is possible.

So far I've not experienced this issue myself. I need to check what RAM I am using.

Dave

[oss003]

I've done some more investigating on the vsync issue.....

No longer seeing it in "Cowboy shootout" but I am seeing it in Acornsoft "Invaders", oddly only when it's in mode 4, and moving the invaders on the screen. Now simultaniously with doing this it will be reading the keyboard and producing sound all of which access the 8255. So I'm going to investigate exactly *WHAT* it is doing to try and see what might be the problem....

Are you sure it's Acornsoft Invaders because there was a glitch in Bug Byte Invaders: viewtopic.php?f=44&t=7320&p=112775&hili ... ch#p112775

Seems that during keyscan, the mode is switched to CLEAR0 for a few msec.

Greetings
Kees

[Prime]

I wonder if you are getting brief periods of bus conflict between the RAM and IC29 (the 8304 buffer).

That is possible, expecially with my write gating activated, but it does it even when just using the /WE pin from the RAM socket.
I am planning to maybe also drive /OE from the CPLD, so that /OE is disabled whenever /WE (from the Atom) is enabled, which should stop both the buffers and the RAM driving against each other.

Looking at your schematic, the RAM is enabled all the time.

Let me have a think about the signal timing and see if I think this is possible.

So far I've not experienced this issue myself. I need to check what RAM I am using.

Yes the RAM is enabled all the time as the 6847 doesn't have a read strobe, it assumes it will always have read access to the RAM. Though when the CPU is accessing the ram /MS is active so the 6847's address lines should be tristated, and it's input data latched by the 74xx573.

Cheers.

Phill.

[Prime]

Are you sure it's Acornsoft Invaders because there was a glitch in Bug Byte Invaders: viewtopic.php?f=44&t=7320&p=112775&hili ... ch#p112775

Seems that during keyscan, the mode is switched to CLEAR0 for a few msec.

Yep that could screw things up

But later investigation found that Invaders doesn't do it with a slower RAM.... Your Manic Miner port also exhibits the same behavior with the fast ram and not with the slow, so I deffo think it's hardware related

Cheers.

Phill.

[tricky]

This is not my area, but I know someone who had problems with fast modern RAM (not in an ATOM), because it was fast enough to interpret noise as signals that the older RAM didn't seem to notice.

[Prime]

This is not my area, but I know someone who had problems with fast modern RAM (not in an ATOM), because it was fast enough to interpret noise as signals that the older RAM didn't seem to notice.

That's the reason that I've had to implement a write strobe gate, as when the 6502 was de-selecting the RAM, the address & data lines where changing before the write enable signal had fully rising, and so random data got written to random locations.

The weird thing is, the horizontal and frame sync signals that I'm processing are generated by the 6847 and don't electrically interact with the RAM, though the do go accross the board near the RAM chip.

Cheers.

Phill.

[Prime]

And now the Atom board is working in the Dragon.....

https://www.facebook.com/media/set/?set ... c310b7126f

Album should be visible to all even without a FB account.

Cheers.

Phill.

[robcfg]

Awesome stuff!

Does your board have a place for an external character eprom?

Could the output of the board be routed to vga or hdmi monitors?

Keep up the good work!

[Prime]

Awesome stuff!

Does your board have a place for an external character eprom?

The version on FB doesn't as it's actually just the Atom board re-purposed....but the Dragon specific version will....first spin currenly on order.
I did also considder this for the Atom version, but needing to fit it inside the Atom case would prevent this due to not having enough board space.......

Could the output of the board be routed to vga or hdmi monitors?

Not natively, you'd need an external converter. Currently will drive anything that can take a TTL 50Hz or 60Hz signal, with composite sync.

Cheers.

Phill.

[Kazzie]

And now the Atom board is working in the Dragon.....

https://www.facebook.com/media/set/?set ... c310b7126f

Album should be visible to all even without a FB account.

Cheers.

Phill.

Looks nice. Might be a future gift for my wife's Dragon, someday.
(A DOS/MMC solution is a higher priority for the time being, though.)

[anightin]

Dear All,

I am looking to add a colour board to my Atom and a 32K RAM expansion if possible. I currently have a mono issue 5 with floating point and 12K RAM.

My monitor is a 27" BENQ IPS Screen

https://www.scan.co.uk/products/27-benq ... cHEALw_wcB

I usually connect my retro-stuff via an OSSC but have also ordered a RetroTINK 2x for some of the display modes not supported by the OSSC e.g. composite output from the ATOM.

I guess the first step is asking nicely on the forum if anyone can help provide the colour board and RAM expansion? Happy to assemble from PCB and components if that helps.

Best wishes

Andy

[hoglet]

I guess the first step is asking nicely on the forum if anyone can help provide the colour board and RAM expansion? Happy to assemble from PCB and components if that helps.

On the colour board topic, your monitor is HDMI only, so some kind of converter is required.

Myself and IanB have been working on a multi-format RGBtoHDMI platform. Initially this was Beeb specific, then we added Atom support, and more recently we've added UK101, ZX80, various PC format, and probably some others.

I have a prototype that works beautifully with the Atom:
viewtopic.php?p=221390#p221390

It doesn't require anything fitting inside the Atom; all the necessary signals are on the PL4 connector.

I'm talking with Ian this week about how we move this forward. I'll keep you posted.

Dave

[anightin]

That's great news, I will watch with keen interest.

For now the video converter I use on my Beeb works fine with the mono Atom.

[roland]

I guess the first step is asking nicely on the forum if anyone can help provide a RAM expansion? Happy to assemble from PCB and components if that helps.

I have ordered a few Yarrb pcb's: viewtopic.php?f=44&t=11373&start=120#p232358

[anightin]

Wonderful, I have put my request in on that thread.

Much appreciated.

[AndyGarton]

What's the best (if any) option for getting hold of a colour board please guys? I'd like two, with a RGB output that I can connect to a Cub monitor ideally.

[AndyGarton]

What's the best (if any) option for getting hold of a colour board please guys? I'd like two, with a RGB output that I can connect to a Cub monitor ideally.

Just one bump to see if anybody knows?

[John Ferguson]

There is one on Ebay with just over 50 minutes to go.

John