ATOM FPGA

emulators, hardware and classic software for atom + system machines
User avatar
oss003
Posts: 3249
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: ATOM FPGA

Post by oss003 » Fri Sep 11, 2015 10:02 am

Hi Dave,

it works like this in Acorn DOS and I copied it.

Yes, it's nice to work on a project with a team.
You keep motivated and triggered.

Greetings
Kees

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

Re: ATOM FPGA

Post by hoglet » Fri Sep 11, 2015 10:43 am

oss003 wrote: it works like this in Acorn DOS and I copied it.
I just tried it in Atomulator and you are right (not that I doubted you :lol: ). The only difference being if the command doesn't exist on drive 0, the current drive is preserved.

I wonder why Acorn decided to implement it this way?

Interestingly, Acorn DFS on the Beeb has the concept of a library directory (set with *LIB). But the current directory is still searched first. Also, there is no difference in behaviour between *RUN COMMAND and *COMMAND.

So I guess it's worth remembering in game loaders to use *RUN as it makes them more portable. I bet there are several games in the SDDOS version of the software archive that will fail because of the behaviour - as the games are executed from DRIVE 2.

Dave

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

Re: ATOM FPGA

Post by oss003 » Fri Sep 11, 2015 10:50 am

Must be something from the System 5.

I guess Acorn wanted you to have a disk with extra commands in drive 0 and work on another drive because the *file is executed from drive 0 but after finishing the command, the drive is set back to drive where it's called from.

Greetings
Kees

eric
Posts: 102
Joined: Mon Apr 21, 2014 2:12 pm
Contact:

Re: ATOM FPGA

Post by eric » Fri Sep 11, 2015 3:41 pm

Ok then ...

So i must see it as a feature in stead of a bug ... as long as you know this behaviour then you can use it as an extra ...
and this is an explanation to me why in the original dos they made *exec *run and *filename .. that sort of seemed all to do the same thing ...
after 35 years i now discover that that was not the case ..-;)

a command set in drive 0 ..

Grx..

Eric

eric
Posts: 102
Joined: Mon Apr 21, 2014 2:12 pm
Contact:

Re: ATOM FPGA

Post by eric » Sun Sep 13, 2015 12:33 pm

Hi guys,

It seems sometimes my bran is not working fully ...
bran is now somewhere in #Exxxx with mmc2 ..

it seems to only find boxes below #BFFF=8 ..
and then when i switch to the box manually by doing ROM11 and UNLOCK it works OK. After that it sees all the boxes also the ones above #BFFF=7.

In my design i maintained #BFFF for Axxx box switching and currently it is the only function for #BFFF.. 16 boxes on Axxx the lower 4 bits active.

#BFFE i use for OS in ROM only the 1st bit switches the upper 16K of the memory map to ram.

#BFFD is my write protect register the lower 2 bits for controlling the wp in Axxx and the upper 16K separately ...

for this build does the PCHARME need a fixed box number ?

any clues ?

Grx..

Eric

PS.
Hardware mode => have been soldering again and built a reset and LED board for in the future frontpanel of the 19" rack .. pic below ..
And have been putting on a 50 pin dual row header with flatcable .. i was lucky to find a twisted pair version in "one of the boxes on the attick" .. so maybe for future LVDS plans ... i hope it works .. also soldered the pairs on the connector length matched and twisted ...
Attachments
FullSizeRender19.jpg
Front panel reset and LED board
FullSizeRender18.jpg
old scsi cable for bringing 48 I/O outside for experimenting

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

Re: ATOM FPGA

Post by oss003 » Sun Sep 13, 2015 12:56 pm

Hi Eric,

BRAN, included in the AtoMMC rom, is compiled for a maximum of 8 roms. The reason for this was that for every rom you add, more space is used from #0400 upwards. Because mostly you only use a few standard roms and there is an option on Phills RAMROM board to load a rom in RAM, this seemed enough.

If you manual switch to a rom above 7, for the next unknown command all roms till 255 will be tested because BRAN compares the romnumber with maxroms and doesn't mask #BFFF (or the shadow byte).

Greetings
Kees

eric
Posts: 102
Joined: Mon Apr 21, 2014 2:12 pm
Contact:

Re: ATOM FPGA

Post by eric » Sun Sep 13, 2015 1:11 pm

Hi Kees,

Understood ..!

So the important boxes i must keep below 8 .. then all goes right .
And if i want to make the upper ones also work do a manual switch and then all will work ..

Grx..

Eric

PS.
The system that i have in front of me now works really well ... i am still impressed about the stability and all the extra's i now can play with keeping the old trusted "directly into the hardware" feeling ... cannot thank you guys enough for this great archievement ..

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

Re: ATOM FPGA

Post by oss003 » Sun Sep 13, 2015 1:48 pm

It's also possible to compile BRAN for 16 roms if you want,will have a look later.

Greetings
Kees

eric
Posts: 102
Joined: Mon Apr 21, 2014 2:12 pm
Contact:

Re: ATOM FPGA

Post by eric » Sun Sep 13, 2015 2:11 pm

Hi Kees,

Allthough my current setup is very ok this way ..
I would not mind using a branq that goes to 16 ..

So yes please ... !! if you can spare the time ...

Grx..

Eric

eric
Posts: 102
Joined: Mon Apr 21, 2014 2:12 pm
Contact:

Re: ATOM FPGA

Post by eric » Sat Sep 19, 2015 9:50 pm

Hi All,

i was in hardware mode again the past day ..

Soldered an LCD 4 lines x 20 chars to the FPGA and some I2C and SPI devices .. (nRF24L01 2,4Ghz transceiver, BMP085 barometric pressure sensor and temp sensor, and a Dallas DS3231 precision clock with battery and also a less accurate temp sensor .. covering the lack of a working Big Benny .. ).
I also now fully populated the 50 pins cable for experiments outside the rack on breadboards .. 48 pins I/O, 3.3v and gnd .. (if i load another bin file in the fpga it can become a logic analyser with 48 inputs .... hmmm -;)
The display backlight and contrast are software controlled via PWM in vhdl .. I found a vhdl module that utilizes 4 bits mode .. was easy to implement .. it uses an array of 80 bytes that are constantly streamed to the display in high speed .. from the atom i have assigned 4 registers in the memory map to control the display (#BFF8 = backlight brightness, #BFF9 = contrast, #BFFA= adress and control register, #BFFB = data in or out of the array).

The mouse problem is solved .. i think a bad cable connection was the reason ...

All is now working the way i expect it to .. wow ..what a superatom . ! .
the rack contains now even 2 atoms .. both in FPGA .. one in the LX9 (i was so lucky to find out the papilio arcade wing fitted in a 19" card slot) and one in the LX45 ..i am thinking about connecting them reading about all these copro's and tubes .. .... i can switch the mouse keyboard and screen via a 2 input KVM switch ...
Now software mode should be coming ..

Grx..

Eric
Attachments
FullSizeRender20.jpg
LCD 20x4
FullSizeRender21.jpg
i2c and spi test board with cheap china logic analyser

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

Re: ATOM FPGA

Post by oss003 » Sun Sep 20, 2015 10:45 am

Hi Eric,

can you upload your AtoMMC rom version so that I can have a look for 16 rom support?

Greetings
Kees

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

Re: ATOM FPGA

Post by hoglet » Sun Sep 20, 2015 11:08 am

It's probably this one:
https://github.com/hoglet67/AtomFpga/bl ... c2_avr.rom

i.e. latest "master" version, but compiled with AVR support.

Dave

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

Re: ATOM FPGA

Post by oss003 » Sun Sep 20, 2015 11:43 am

Ok, here is the 16 rom version.

Greetings
Kees
Attachments
atommc2_avr-16roms.zip
(2.98 KiB) Downloaded 36 times

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

Re: ATOM FPGA

Post by roland » Sun Sep 20, 2015 2:34 pm

Nice work, Eric =D>

I'm looking forward to meet your new Atom....
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: ATOM FPGA

Post by 1024MAK » Sun Sep 20, 2015 4:00 pm

Two fast cool Atoms, well done 8) =D>

Mark

eric
Posts: 102
Joined: Mon Apr 21, 2014 2:12 pm
Contact:

Re: ATOM FPGA

Post by eric » Mon Sep 21, 2015 1:48 pm

Hi all,

@Kees and Dave --> new Erom with 16 box patched branq + mmc works ... after the 1st tests no errors reported ... it now finds boxes above 7 too right after reset without any manual actions to 1st switch high ..this is the way i like it to behave ..
Thanks for the time to make this for me ... it will be my standard rom for exxx in the default load set after booting the FPGA from now on ..

@Roland ... i hope to attend the next tech meeting again .. last time went wrong because of a family tragedy .. something i could not escape ..
At the next meeting we can match up the 2 newborn 2015 atoms . yours and mine . where yours is muuuch more authentic and closer to the original 1979 model ...

@Mark yes 2 atoms in the top rack in fpga and a real 6502 based system underneath it .. nice setup to cherish for the years to come .. i must sometimes stop myself from going around in circles in my mind about all the possibilities i have now and kick myself under the b.. to actually start moving and do something with the ideas .. this is an area where you can spend a lot of creativity and time to make things the way you really want it without all the layers underneath you normally in the present computing world ...

Grx...

Eric

eric
Posts: 102
Joined: Mon Apr 21, 2014 2:12 pm
Contact:

Re: ATOM FPGA

Post by eric » Sat Sep 26, 2015 1:34 pm

Hi guys,

I have been doing some vhdl in combi with the LCD display and the T65 core ..
I tapped off the registers and can use the LCD display now in 2 different modes ..
mode one : all characters write and readable from the atom via 2 Bxxx registers .. or ..
mode two : real time debug mode displaying the CPU and bus info ..

I have put some extra vhdl in to stop the cpu and do step by step execution using the option to keep the system clock low when i want it to stop ..
with F6 you can manually do this .. halt the atom .. F5 let it continue ...
I created a trap register set .. in the Bxxx block as well and the option to let the cpu run full speed until the address bus matches these registers and then stop the cpu and let you do step by step execution with F7 .. if you want it to run normally again until it reaches the trap address you can press F8 ...

on the pic the debug screen ...
with Ad: address Di: data in for cpu Do: data out from cpu
A: X; and Y: the obvious registers .. SP: stack pointer (SP: is not the right one yet ... maybe got the wrong signal tapped from the core .... is under investigation ... -:) )
PC: program counter S: status register Tr: trap address to stop cpu
and last line when it recognises a 6502 instruction .. display it in text ..
Off course all values in hex ....

If interested i am happy to share my code with everyone ...

Grx...
Eric
Attachments
FullSizeRender22.jpg
Debug LCD

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

Re: ATOM FPGA

Post by 1024MAK » Sat Sep 26, 2015 4:41 pm

:D =D>

Mark

User avatar
fordp
Posts: 1050
Joined: Sun Feb 12, 2012 9:08 pm
Location: Peterborough, England
Contact:

Re: ATOM FPGA

Post by fordp » Wed Nov 04, 2015 12:25 pm

Do you still want a DE1?
hoglet wrote:Phil,

The DE1 looks like an excellent board, and has everything needed (and more) including on-board SRAM and FLASH. Most of the Atom functionality is in Atomic_core and the VHDL here is pretty generic RTL VHDL.

You'll need to create a new top level VHDL module that's specific to your DE1, that contains:
- Atomic_core
- clock generation for 12.5875MHz (VGA), 16MHz (Core) and 32MHz (SID) clocks.

Use Atomic_top.vhd as your starting point, as this uses external SRAM, which is what you have in the DE1.

The tricky part will be the clock generation from the available 24MHz, 27MHz and 50MHz clocks. You'll have to use the Altera PLL clock generation to generate the required inputs. e.g. Using the 24MHz clock the following seem plausible:
  • 12.5875MHz ~= 24MHz * 11 / 21
  • 16MHz = 24MHz * 4 / 6
  • 32MHz = 24MHz * 4 / 3
One thing I should look at doing is to externalize the ROMs, so that these can use external components if available (like on the DE1). This would make the software updates much easier!

Maybe I should look at procuring a DE1 as well - you can't have too many FPGA Boards. :D

Dave
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: ATOM FPGA

Post by hoglet » Wed Nov 04, 2015 1:13 pm

Hi Ford,

It's quite a bit of work to port a project to a completely new platform, and I've got quite a few new projects on the go. I'm trying to be quite focussed at the moment on the Papilio Duo platform (which means the Xilinx tool chain rather than Altera).

So thanks for the kind offer, but I'll probably decline for the time being.

Dave

User avatar
fordp
Posts: 1050
Joined: Sun Feb 12, 2012 9:08 pm
Location: Peterborough, England
Contact:

Re: ATOM FPGA

Post by fordp » Wed Nov 04, 2015 5:34 pm

Well I have a spare one still in it's box. PM me if you change your mind.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: ATOM FPGA

Post by hoglet » Thu Nov 12, 2015 10:22 am

fordp wrote:Well I have a spare one still in it's box. PM me if you change your mind.
PM Sent :D :D :D

User avatar
fordp
Posts: 1050
Joined: Sun Feb 12, 2012 9:08 pm
Location: Peterborough, England
Contact:

Re: ATOM FPGA

Post by fordp » Thu Nov 12, 2015 10:46 am

Hi Dave,

I will send the DE1 tomorrow!

FordP
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: ATOM FPGA

Post by hoglet » Thu Nov 12, 2015 11:14 am

fordp wrote: I will send the DE1 tomorrow!
Much appreciated!

I've downloaded the Altera Quartus design tools, and hope to have a play later.

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

Re: ATOM FPGA

Post by TheCorfiot » Fri Nov 13, 2015 12:42 pm

Ooooh I have a DE1, please Dave work your magic, it's a cracking board.

Pretty please with sugar and a cherry on top :)

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

Re: ATOM FPGA

Post by hoglet » Fri Nov 13, 2015 12:58 pm

TheCorfiot wrote:Ooooh I have a DE1, please Dave work your magic, it's a cracking board.

Pretty please with sugar and a cherry on top :)
I'm working on re-factoring BeebFpga to more easily support additional boards as we speak.

Are you also interested in Electron Fpga and Atom Fpga?

PhilYoung
Posts: 204
Joined: Sun Jun 12, 2011 5:55 pm
Contact:

Re: ATOM FPGA

Post by PhilYoung » Fri Nov 13, 2015 1:06 pm

One potential pitfall with the DE1 is that at some point they changed the SRAM used from IS61LV25616AL to IS61WV25616EDBLL. Although the data sheets suggest that these two have very similar timing there seems to have been a lot of difficulty getting the 'bad' later SRAM to work reliably when projects have been developed on a board using the 'good' SRAM. See this thread for instance:

http://www.minimig.net/viewtopic.php?f=9&t=609

The best solution seems to be to physically swap the SRAM chip, which I haven't quite had the nerve to do yet but doesn't look too horrendously difficult.

So, getting to the point, it would be a good idea to check and be specific about which SRAM version DE1 is being targeted. If you can get it to work with the 'bad' SRAM then that would be ideal, it seems to work fine at lower speeds,

Cheers,

Phil Young

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

Re: ATOM FPGA

Post by hoglet » Fri Nov 13, 2015 1:46 pm

PhilYoung wrote: So, getting to the point, it would be a good idea to check and be specific about which SRAM version DE1 is being targeted. If you can get it to work with the 'bad' SRAM then that would be ideal, it seems to work fine at lower speeds,
Thanks for that head-up.

BeebFPGA is currently driving the memory interface pretty fast (32MHz), but I think this could be reduced I think to just 4MHz (like a real Beeb).

When I first moved this design to the Papilio the SRAM was very unreliable. But then I noticed that in the original design, the WE signal was not gated with the clock. Sometimes you can get away with this, but you are in danger of violating hold times. Gating it with the 32MHz clock shortens the duration of the write signal, and buys you an extra 16ns of timing margin. I wonder if it's a similar issue on the DE1?

Dave

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

Re: ATOM FPGA

Post by TheCorfiot » Fri Nov 13, 2015 2:15 pm

hoglet wrote:
TheCorfiot wrote:Ooooh I have a DE1, please Dave work your magic, it's a cracking board.

Pretty please with sugar and a cherry on top :)
I'm working on re-factoring BeebFpga to more easily support additional boards as we speak.

Are you also interested in Electron Fpga and Atom Fpga?
You are such a darling ;)
I'm mainly interested in BeebFpga and AtomFpga....
I have got Mike Sterlings BeebFpga running but it has many bugs, luckily my 2 DE1's have the good SRAM.

Cheers mate
Bas :)

PhilYoung
Posts: 204
Joined: Sun Jun 12, 2011 5:55 pm
Contact:

Re: ATOM FPGA

Post by PhilYoung » Fri Nov 13, 2015 2:42 pm

hoglet wrote:
PhilYoung wrote: So, getting to the point, it would be a good idea to check and be specific about which SRAM version DE1 is being targeted. If you can get it to work with the 'bad' SRAM then that would be ideal, it seems to work fine at lower speeds,
Thanks for that head-up.

BeebFPGA is currently driving the memory interface pretty fast (32MHz), but I think this could be reduced I think to just 4MHz (like a real Beeb).

When I first moved this design to the Papilio the SRAM was very unreliable. But then I noticed that in the original design, the WE signal was not gated with the clock. Sometimes you can get away with this, but you are in danger of violating hold times. Gating it with the 32MHz clock shortens the duration of the write signal, and buys you an extra 16ns of timing margin. I wonder if it's a similar issue on the DE1?

Dave
I wouldn't like to say, we're well beyond my competence here ! I spent a lot of time researching this to try to get the Mike Stirling Spectrum project working, and it seems that the problem has shown up in lots of different projects - the one I linked to, the 'Zet' project and the CoCo3 one for example.

The suggested solutions (which I tried as far as possible) that I can remember were:

a timing constraint on the control lines to the SRAM (which sound in the same ball park as your comment above) - I'm not sure I implemented this correctly
change the impedance of those lines in the constraints file - this changed the Spectrum from not working at all to working for a short while so clearly did some good
change the output current capacity of those lines down from 20mA to 4mA - not sure if I tried this.

I could only get the Grant Searle Multi comp as a 6502 working on the DE1 at maximum 5MHz, so 4MHz might be okay for a BBC.

This might be good motivation to try the RAM swap, I've got a box of old busted CD-ROMs and HDDs to practice on first,

Cheers,

Phil Young

Post Reply

Return to “acorn atom and acorn system series”