Atom Tube Interface

emulators, hardware and classic software for atom + system machines
Post Reply
User avatar
hoglet
Posts: 9225
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Atom Tube Interface

Post by hoglet » Sun Sep 13, 2015 6:26 pm

Hi Guys,

I want to have a go this week at interfacing the Matchbox Co Pro to an Atom.

I'm mulling over the best how best to do this.

1. Where to connect this to?

a) To PL6/7

The advantage of this is that this connector is present on the New 2015 Atom, as well as on the original Atom. It's normally unused, and so the Matchbox Co Pro could sit internally.

The disadvantage is that the data bus is separated by an 8304 bus buffer, that is only selectively enabled.

b) To PL8

The advantage here is that this has the right set of signals coming directly from the 6502. Plus a nB400 that could be used to select the Tube chip.

The disadvantage is that in many peoples Atoms, this is occupied by AtoMMC2, which I think takes over the whole of the B400-B7FF block.

Another disadvantage is in the new Atom this connector doesn't exist.

2. What address should this be decoded to?

I think the best answer is somewhere in Bxxx.
- #BCxx is normally free (apart from some disc controllers at #BC48)
- #BDxx is used by the GODIL and Atom SID
- #BExx is normally free
- #BFxx is normally free, except BFFx is used by BRAN for ROM switching

Where does Phill's new disk interface sit?

My preference here is #BExx

So my plan is to make a small adapter PCB:
- 2x32 connector to PL7 (internal)
- Small PAL to decode nBExx and use this as the Tube CS
- 2x20 right angle IDC connector to Matchbox Co Pro
- Flying lead to allow nBExx to connect to IC5 pin 1 to enable data bus buffers

Anyone see any flaws in this?

Dave

User avatar
hoglet
Posts: 9225
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom Tube Interface

Post by hoglet » Sun Sep 13, 2015 7:03 pm

Another consideration: Phill's RAM ROM board can also drive the bus buffers:

Code: Select all

	// IC2 / IC3 / IC4 enable control.                                                                                     
	// Enable the buffers when an appropriate address is accessed and 
	// any of the following is true :
	// Onboard $0a00-$0aff ram is disabled
	// Onboard $e000-$efff dos rom is disabled
	// I/O in the region $BC00-$BFF0 is accessed.
	// To enable this IC5 must be removed and the NBuffCtl output linked to pin 8
	// of it's socket.
	assign 	DskRAMBuffEn	= (~DskRAMEN && ((Addr>=16'h0A00) && (Addr<=16'h0AFF)));
	assign 	DskROMBuffEn	= (~DskROMEN && (Addr>=16'hE000) && (Addr<=16'hEFFF));
	assign 	IOBuffEn		= ((Addr>=16'hBC00) && (Addr<=16'hBFF0));
	
	assign 	BuffCtl			= (DskRAMBuffEn | DskROMBuffEn | IOBuffEn);
	assign 	NBuffCtl		= ~BuffCtl;
As a short term solution, I could just use NBuffCtl as the Tube Chip select, as well as the buffer enable signal.

Then all I need to hook it up is a few wires :evil:

Dave

User avatar
oss003
Posts: 3273
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: Atom Tube Interface

Post by oss003 » Sun Sep 13, 2015 8:25 pm

Hi Dave,

at last .... you did start the original Matchbox Co Pro in the Atom topic ... :lol: :lol: :lol:
This is a nice addition to the Atom........ =D>

I think an internal Co Pro on PL7 is a good solution.

For opening the bus databuffer for the Tube address, I see 3 options:

1) If you install a socket for a PAL on the adapter PCB, you can use that with a wire to pin1 of IC5 in an original Atom.

2) On Phill's RAMROM board, the CPLD can be reprogrammed to open the bus for the Tube address using the wire to pin8 of IC5.

3) On Rolands Atom board, the CPLD can be reprogrammed to open the bus for the Tube address.

I think the Tube address at #BExx is a good solution.

Greetings
Kees

User avatar
hoglet
Posts: 9225
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom Tube Interface

Post by hoglet » Sun Sep 13, 2015 8:41 pm

A few wires later....
IMG_1088.JPG
We have contact with the other side:
IMG_1089.JPG
\:D/ \:D/ \:D/ \:D/ \:D/ \:D/
Dave

User avatar
oss003
Posts: 3273
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: Atom Tube Interface

Post by oss003 » Sun Sep 13, 2015 8:52 pm

Take it easy Dave, the week has just started ..... :lol: :lol: :lol:
Did you reprogram the CPLD on the RAMROM board and also use this signal as Tube select?

Greetings
Kees

User avatar
hoglet
Posts: 9225
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom Tube Interface

Post by hoglet » Sun Sep 13, 2015 8:59 pm

oss003 wrote:Did you reprogram the CPLD on the RAMROM board and also use this signal as Tube select?
I just used it as is, so it's mapped to #BC00-#BFEF. Everything else is internal. I don't have a GODIL in this Atom, so it's fine for development.

Dave

User avatar
1024MAK
Posts: 9969
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Atom Tube Interface

Post by 1024MAK » Sun Sep 13, 2015 9:46 pm

Well done Dave =D> =D> =D>

Now, when are you going to invent a time machine so that I can use it to make time to play with all your projects :mrgreen:

Seriously, I do enjoy reading (and looking at the techie p0rn pictures) about your adventures and the progress you make. Please do continue :D

Mark

Prime
Posts: 2861
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Atom Tube Interface

Post by Prime » Sun Sep 13, 2015 10:44 pm

Hi all,

New disk interface's I/O will be mapped at one of two ranges of addresses...

$BC10-$BC1F For use in Roland's board.
$EFF0-$EFFF For use in a traditional Atom, as it doesn't open the bus buffers for
the $Bxxx block.

This is selected by a jumper on the disk interface.

I think the approach that I would take is would be to take the current chip enable signal from pin 8 of IC5 or 19 of IC4 and combine this with your selected range and then pass that to IC4 pin 19. That way it doesn't matter if it's already enabled as you enable it, this should work for all configurations.

Cheers.

Phill.

User avatar
roland
Posts: 3847
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: Atom Tube Interface

Post by roland » Sun Sep 13, 2015 11:09 pm

oss003 wrote: 3) On Rolands Atom board, the CPLD can be reprogrammed to open the bus for the Tube address.
There's no need to.... for all unused addresses the bus is already opened by the cpld.

Looking forward to my co-pro board 8)
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
hoglet
Posts: 9225
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom Tube Interface

Post by hoglet » Mon Sep 14, 2015 1:19 pm

Hi Guys,

I've been working on the Atom Tube host this morning. I started with Jonathan's work from here:
http://mdfs.net/Software/Tube/Atom/

The development cycle was a bit slow, because this is BBC Basic source, and the path to end up with an Atom ATM file was quite involved. It was also very hard to debug on the Atom, because it copies all the code really low down in memory (like the Tube Host code on the Beeb). So when you press break, things get corrupted.

So, what I did was to port it over to BeebASM, and then change it to compile and run from #4000:
https://github.com/hoglet67/CoPro6502/b ... omHost.asm

I've had to make quite a few changes:
- added some debug code to see what's sent over the tube
- added null implementation of OSWORD and OSBYTE
- got rid of the self-modifying code (so it could be ROMed)
- fixed a few bugs (JGH, we can go through these if you like)

I'm now at the stage where I can type commands to the Co Processor,
and basic escape and error handling is working:
IMG_1091.JPG
The next milestone is data transfers, so we can get some software loaded.

Now, porting the raw data transfer code from the Beeb Tube Host seems do-able, but the problem is that for *LOAD, *RUN and *SAVE to work, the file system has to know to call the tube data transfer. That would mean changes to AtoMMC, but it's worse than this...

On the Beeb, the file system knows to do a tube transfer because OSFILE uses 32-bit addresses, FFFFxxxx are on the host, everything else is assumed to be on the parasite. But on the Atom, OSFILE only uses 16 bit addresses.

Jonathan, do you have any thoughts on how best to work around this?

Dave

User avatar
hoglet
Posts: 9225
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom Tube Interface

Post by hoglet » Mon Sep 14, 2015 2:24 pm

Before trying to tackle LOAD and SAVE, just being able to do a language transfer on start-up from a fixed location in Atom RAM (e.g. #4000-#7FFF) might useful.

The idea is you could:
- *LOAD BASIC2 4000
- *TUBE
and then on start-up the tube host would do the language transfer.

I think that's what I'll try to do next, as it should be more achievable. It also doesn't require any messing with OSFILE or AtoMMC2.

Dave

User avatar
roland
Posts: 3847
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: Atom Tube Interface

Post by roland » Mon Sep 14, 2015 2:43 pm

You can also write a new (basic) statement like TLOAD which reads the file and copies it to the co pro. TLOAD can read the entire file into Atom memory, or just read it as a random file so you don't need a buffer in the Atom.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
jgharston
Posts: 3994
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Atom Tube Interface

Post by jgharston » Mon Sep 14, 2015 3:12 pm

hoglet wrote:The development cycle was a bit slow, because this is BBC Basic source, and the path to end up with an Atom ATM file was quite involved.
I've been meaning to write a BBC BASIC source to ASM-type source converter tool, but haven't got around to it yet. Most of it is fairly programatically simple, and some things are simplified if you ensure the BASIC source is written in a "tidy" manner.
hoglet wrote:I'm now at the stage where I can type commands to the Co Processor, and basic escape and error handling is working:
Woo hoo! Always the first milestone.
hoglet wrote:...the problem is that for *LOAD, *RUN and *SAVE to work, the file system has to know to call the tube data transfer. ...
On the Beeb, the file system knows to do a tube transfer because OSFILE uses 32-bit addresses, FFFFxxxx are on the host, everything else is assumed to be on the parasite. But on the Atom, OSFILE only uses 16 bit addresses.
My notes I sketched out would do this, similar to the CUBE host:

Don't pass them on to the filing system. Incoming *commands are parsed by the Tube Host code before passing them to the Atom's OSCLI, and match *LOAD, *SAVE and *RUN and parse the parameters and pass them on to the Tube Host's OSFILE handler, not to the Atom MOS.

The Tube Host's OSFILE handler does not call the Atom MOS OSLOAD/OSSAVE but implements LOAD and SAVE manually, LOAD would do OPENIN(loadfile), repeat TubeSend(BGET), until EOF; SAVE would do OPENOUT(savefile), repeat, BPUT(TubeRead), until EOF. (This is the same as the TubeHost running on Windows)

The problem is what to do with load/exec addresses. The Atom API only passes 16-bit addresses (even though AtomDOS disks are capable of storing 18-bit addresses as it is a subset of DFS, the extra bits are unaccessible without bypassing the API and building in assumptions of what device you're using)

There's also the problem that there's no "Read File Info" or "Set File Info" call in the Atom API, so reading/writing the file addresses could be tricky. I think for LOAD the control block is filled in (as on the BBC), but the only way of writing addresses is when SAVEing. My thoughts were that to implement OSFILE's SAVE you'd do an Atom OSSAVE to create a dummy file, then OPENOUT to it.

So, something like this:
.TubeOSFILE
get parameters
cmp #0:beq TubeSave
cmp #255:beq TubeLoad
return A preserved for 'unimplemented'
return parameters

.TubeSave
if ControlBlock?4,5=&FFFF:beq TubeSaveIOMemory
call OSSAVE to save file ; set load/exec address
call OSFIND to openout the file
call &406 to start a Client->Host transfer
repeat
read from Tube
OSBPUT to file
until all done
update parameter block
return with A=1

.TubeLoad
if ControlBlock?4,5=&FFFF:beq TubeLoadIOMemory
call OSFIND to openin the file
call &406 to start a Host->Client transfer
repeat
OSBGET from file
write to Tube
until all done
update parameter block ; probably only 'length' is do-able
return with A=1

.TubeOSCLI
read string from Tube
match *LOAD, *SAVE, *RUN, */ commands
if no match, pass to OSCLI
parse *LOAD, *SAVE, pass to TubeOSFILE.
parse *RUN, */, do a LOAD, then a TubeExecute

So, *LOAD, *SAVE, *RUN and OSFILE calls to the Client would be passed to the Host, and the Host code would implement them rather than depending on the filing systems's non-existant knowledge of the Tube.
hoglet wrote:Before trying to tackle LOAD and SAVE, just being able to do a language transfer on start-up from a fixed location in Atom RAM (e.g. #4000-#7FFF) might useful.
That looks like the simplest thing to get up and running, as it's essentially the same as getting language transfer on Break working.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

User avatar
hoglet
Posts: 9225
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom Tube Interface

Post by hoglet » Mon Sep 14, 2015 4:38 pm

jgharston wrote:
hoglet wrote:Before trying to tackle LOAD and SAVE, just being able to do a language transfer on start-up from a fixed location in Atom RAM (e.g. #4000-#7FFF) might useful.
That looks like the simplest thing to get up and running, as it's essentially the same as getting language transfer on Break working.
Second milestone:
IMG_1092.JPG
This involved porting the BBC tube host data transfer code, and then forcing a language transfer to happen on start-up.

Latest code in github:
https://github.com/hoglet67/CoPro6502/b ... omHost.asm

Jonathan, I'll think about your other suggestions later. But using the AtoMMC2 random access file BGET/BPUT to implement load and save will be pretty slow I think. In AtoMMC there is sector buffering, but this is done by the PIC rather than the Atom. Each one-byte BGET will map to a seperate AtoMMC2 PIC command. I would expect this to top out at maybe ~1000 bytes/second.

Dave
Last edited by hoglet on Mon Sep 14, 2015 8:58 pm, edited 2 times in total.

User avatar
sirmorris
Posts: 786
Joined: Wed Feb 11, 2009 12:18 pm
Location: oxfordshire uk
Contact:

Re: Atom Tube Interface

Post by sirmorris » Mon Sep 14, 2015 7:26 pm

:shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock:

User avatar
danielj
Posts: 8123
Joined: Thu Oct 02, 2008 5:51 pm
Location: Manchester
Contact:

Re: Atom Tube Interface

Post by danielj » Mon Sep 14, 2015 8:43 pm

sirmorris wrote::shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock: :shock:
That. :shock: =D>
d.

User avatar
TheCorfiot
Posts: 671
Joined: Mon Jan 08, 2007 5:22 pm
Contact:

Re: Atom Tube Interface

Post by TheCorfiot » Mon Sep 14, 2015 9:39 pm

This is just jaw dropping amazing..

Dave you really are one clever son of a........lol

Congrats :)

Kees, When we getting a port of copro elite lol

:D

User avatar
roland
Posts: 3847
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: Atom Tube Interface

Post by roland » Mon Sep 14, 2015 10:44 pm

What's next? Running ms windows 1.0 on the 80186 copro :lol:

This is really great stufff =D> =D> =D>

Dave, you cannot surprise me any more. From now on I will always expect the unexpected. You can make the Atom and BBC do whatever is technical possible.

But also a great compliment to JGH because he has also done a big and great job with the tube host and client software =D> =D> =D>
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
1024MAK
Posts: 9969
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Atom Tube Interface

Post by 1024MAK » Tue Sep 15, 2015 12:14 am

Err.... <mouth opens, but no sound comes out>....

<After a pause, brain and mouth regain synchronisation>...

Dave - Are you from the some distant future and have travelled back in time to improve the computers for us mere mortals?

And of course, big thanks to JGH for the code :D

So, um, what next, I wonder :shock:

Whoops, nearly forgot to say, excellent work on both the Atom Tube system and of course the 68k co-processor for the Matchbox =D> \:D/ =D> \:D/ =D> \:D/ =D>

Oh, and yes, of course we want to see more :mrgreen:

Maybe you could work with Tricky and get an Atom (or Beeb) to talk in life like English like the HAL 9000 computer or the Star Trek computers? Should be plenty of RAM on the 68k co-pro...

Mark

User avatar
Multiwizard
Posts: 1880
Joined: Wed Jan 11, 2012 9:03 pm
Contact:

Re: Atom Tube Interface

Post by Multiwizard » Tue Sep 15, 2015 6:22 am

What Roland and Mark said :D

It's really amazing what is all happening... =D> \:D/ =D>


Greetings, Wim... :-)

User avatar
jgharston
Posts: 3994
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Atom Tube Interface

Post by jgharston » Tue Sep 15, 2015 9:15 am

hoglet wrote:... But using the AtoMMC2 random access file BGET/BPUT to implement load and save will be pretty slow I think. In AtoMMC there is sector buffering, but this is done by the PIC rather than the Atom. Each one-byte BGET will map to a seperate AtoMMC2 PIC command. I would expect this to top out at maybe ~1000 bytes/second.
The problem is the Atom API doesn't have a "read information on this file" call (eg OSFILE 5) or a "read part of this file" call (eg OSGBPB 3 or 4), so reading byte by byte is the only way to get the contents of a file when those contents need to go somewhere other than host memory.

You could do an OPENIN, then a OSRDST to read the file EXT, and if it is small enough to fit in a local buffer, then use OSLOAD and send it from the buffer. Similarly the other say for small SAVEs. But otherwise, there's no way to say "give me the next 256 bytes so I can shoot them across the Tube" without bypassing the Atom API and hard-wiring assumptions about the devices being accessed.

More from my notes: when the Atom causes an error it prints a message then simply barrels into a BRK. That's why the BRK handler currently just sends 'HOST ERROR' to the client. The only way of identifying an error is by its address. I'd been thinking of having some sort of lookup table that would translate 'BRK at &EA0F' into 'File not found' or whatever. You'd still unavoidably end up with the message printed before the BRK is ecxecuted, but the Client ON ERROR mechanism would get a better error message.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

User avatar
sPhilMainwaring
Posts: 291
Joined: Tue Jan 15, 2013 7:57 pm
Location: Mid Wales
Contact:

Re: Atom Tube Interface

Post by sPhilMainwaring » Tue Sep 15, 2015 12:30 pm

No way! You guys are mental!

(Translation ... incredible work :) )

But I see here we go again with a big white board full of ATOM memory map drawings :lol:

User avatar
oss003
Posts: 3273
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: Atom Tube Interface

Post by oss003 » Tue Sep 15, 2015 12:46 pm

sPhilMainwaring wrote:But I see here we go again with a big white board full of ATOM memory map drawings :lol:
Ah yes, but this times far beyond the 64KB limit ......... 8)

Greetings
Kees

User avatar
sPhilMainwaring
Posts: 291
Joined: Tue Jan 15, 2013 7:57 pm
Location: Mid Wales
Contact:

Re: Atom Tube Interface

Post by sPhilMainwaring » Tue Sep 15, 2015 12:54 pm

Is the Atom PDP 11 Co-Pro working yet? :lol:

User avatar
hoglet
Posts: 9225
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom Tube Interface

Post by hoglet » Tue Sep 15, 2015 2:06 pm

sPhilMainwaring wrote:Is the Atom PDP 11 Co-Pro working yet? :lol:
Here you go:
IMG_1094.JPG
Dave

User avatar
sPhilMainwaring
Posts: 291
Joined: Tue Jan 15, 2013 7:57 pm
Location: Mid Wales
Contact:

Re: Atom Tube Interface

Post by sPhilMainwaring » Tue Sep 15, 2015 2:55 pm

Brilliant ... so with a 6502 co-pro it runs BBC Basic I would imagine?

Is there a benchmark test like the beeb or does it need an RTC?

User avatar
hoglet
Posts: 9225
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom Tube Interface

Post by hoglet » Tue Sep 15, 2015 3:05 pm

sPhilMainwaring wrote: Is there a benchmark test like the beeb or does it need an RTC?
It should run the same speed as the corresponding Co Pro on the Beeb.

There's no implementation of the OSWORD supporting TIME at present.

Dave

User avatar
roland
Posts: 3847
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: Atom Tube Interface

Post by roland » Tue Sep 15, 2015 3:38 pm

sPhilMainwaring wrote:Is there a benchmark test like the beeb or does it need an RTC?
Maybe we can design a small pcb that fits on the internal PL6/7 connector that decodes the address for the tube with the connector for the co-pro board and with a simple rtc on it.
Last edited by roland on Thu Sep 17, 2015 7:44 pm, edited 1 time in total.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
hoglet
Posts: 9225
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom Tube Interface

Post by hoglet » Tue Sep 15, 2015 4:01 pm

We could also do this in software on the host using VIA interrupts, just like the model B does.

User avatar
jgharston
Posts: 3994
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Atom Tube Interface

Post by jgharston » Tue Sep 15, 2015 4:20 pm

sPhilMainwaring wrote:Is there a benchmark test like the beeb or does it need an RTC?
ClockSp is a BBC BASIC benchmark test, and it just needs the standard elapsed-time centisecond timer read with TIME. No RTC needed, just a source of 100Hz (or multiple/submultiple*) interupts updating a ticker.

* The Spectrum has 50Hz interupts, so the TIME ticker advances by 2.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_

Post Reply

Return to “acorn atom and acorn system series”