
YARRB [SOLD OUT]
- TheCorfiot
- Posts: 663
- Joined: Mon Jan 08, 2007 5:22 pm
- Contact:
Re: YARRB
I wouldnt mind a board if you have a spare please


Re: YARRB
No problem, I have enough boards
How many would you like to have?

How many would you like to have?
FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
Today I programmed the CPLD and installed the board. It behaved like I expected: it didn't work 
I did some simple investigations. There is a Phi0 going into the processor and there is a Phi2 out. I also saw activity on the address and data busses with my logic probe. So the processor seems to be running (but it always does if there is power and a clock).
Time to plug in the ICE-T65. Reading from the rom doesn't give the expected data (only #00) and the ram test also fails. But what upsets me most is that even when I remove I cannot do a successful ram test in the video memory. Also when I reinstall the original zero page memory, I should be able to test it.
I have to leave now but my next test will be to reinstall the original rom (IC20) and the zeropage. The Atom should be running then because it's nothing else but an extension socket with only a clock divider. If that still doesn't work, I'll have check the clock signal or I completely messed up the bus on my PCB.
To be continued .... as usual ....

I did some simple investigations. There is a Phi0 going into the processor and there is a Phi2 out. I also saw activity on the address and data busses with my logic probe. So the processor seems to be running (but it always does if there is power and a clock).
Time to plug in the ICE-T65. Reading from the rom doesn't give the expected data (only #00) and the ram test also fails. But what upsets me most is that even when I remove I cannot do a successful ram test in the video memory. Also when I reinstall the original zero page memory, I should be able to test it.
I have to leave now but my next test will be to reinstall the original rom (IC20) and the zeropage. The Atom should be running then because it's nothing else but an extension socket with only a clock divider. If that still doesn't work, I'll have check the clock signal or I completely messed up the bus on my PCB.
To be continued .... as usual ....
FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
Hi Roland,
I spotted one small bug in the VHDL:
should be:
Without this you will have data bus conflicts at:
-3FFE/F
-7FFE/F
-FFFE/F (the IRQ/BRK vector)
But I doubt this is the cause of your problems.
Can you make sure the clock is running at 1MHz? It's possible ICE-T65 would be problematic at faster clocks.
One last thought: What's the contents of your ROM? It looks like on power up Atom addresses 0xC000-0xFFFF will be mapped to ROM address 0x14000-0x17FFF. Is that what you intended?
Dave
I spotted one small bug in the VHDL:
Code: Select all
-- read registers
DD <= regBFFE when (nBFFX = '0' and RW = '1' and RS = '0') else
regBFFF when (nBFFX = '0' and RW = '1' and RS = '1') else
(others => 'Z');
Code: Select all
-- read registers
DD <= regBFFE when (A15 = '1' and A14 = '0' and nBFFX = '0' and RW = '1' and RS = '0') else
regBFFF when (A15 = '1' and A14 = '0' and nBFFX = '0' and RW = '1' and RS = '1') else
(others => 'Z');
-3FFE/F
-7FFE/F
-FFFE/F (the IRQ/BRK vector)
But I doubt this is the cause of your problems.
Can you make sure the clock is running at 1MHz? It's possible ICE-T65 would be problematic at faster clocks.
One last thought: What's the contents of your ROM? It looks like on power up Atom addresses 0xC000-0xFFFF will be mapped to ROM address 0x14000-0x17FFF. Is that what you intended?
Dave
Re: YARRB
The content of the rom is equal to the rom that Kees has on his ramrod board. So it should map to some decent code.
I didn't look with my logic analyser at the 1 MHz clock yet. I'll do this next week. I will also fix the BFFE bug. The Atom2k15 gets a real nBFFx select signal and I forgot to adjust this.
I didn't look with my logic analyser at the 1 MHz clock yet. I'll do this next week. I will also fix the BFFE bug. The Atom2k15 gets a real nBFFx select signal and I forgot to adjust this.
FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

- 1024MAK
- Posts: 9393
- Joined: Mon Apr 18, 2011 4:46 pm
- Location: Looking forward to summer in Somerset, UK...
- Contact:
Re: YARRB
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki - for answers to many questions...
Fault finding index • Acorn BBC Model B minimal configuration • Logic Levels for 5V TTL Systems
BeebWiki - for answers to many questions...
Fault finding index • Acorn BBC Model B minimal configuration • Logic Levels for 5V TTL Systems
Re: YARRB
I can give three options about the ramrod:
1. Kees has some bizarre hobbies
2. The spelling checker didn't understand ramrom
3. I was in a local pub, drinking my 5th beer because Yarbb doesn't work
Anyway, I checked the clock and it turned out to be 250kHz.
The board needs 4 MHz clock input so I had forgotten about this and I bend out pin 10 of IC44 (74LS393) the clock divider. Then I soldered a wire from pin 13 of the 393 to pin 37 of the 6502 socket. After that, I had an input clock to the CPU (or Godil) of 1 MHz. Guess what:
After running this test, I ran it again and got no errors. But on a third run there was another error at another address, It's not quite stable yet.
1. Kees has some bizarre hobbies
2. The spelling checker didn't understand ramrom
3. I was in a local pub, drinking my 5th beer because Yarbb doesn't work
Anyway, I checked the clock and it turned out to be 250kHz.

After running this test, I ran it again and got no errors. But on a third run there was another error at another address, It's not quite stable yet.
FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
Some other tests performed:
* I can read and write to the via
* I can manually init the 8255 and detect that the shift key is pressed or not
* Memory test of video ram still fails, almost 100% errors
* Reading from rom gives always #00 from #C000 - #FFFF
* Reading from #Axxx also reads #00
* Memtest on #BFFE/#BFFF succeeds
So I wonder ... can ICE-T65 test the video ram in a normal Atom? I used it only in Godil configurations. And, does my eeprom hold any data? How to check without appropriate hardware?
BTW ... the answer to the question of the ramrod is probably a combination of the answers 2 and 3. When I drink beer my spell checker starts failing
* I can read and write to the via
* I can manually init the 8255 and detect that the shift key is pressed or not
* Memory test of video ram still fails, almost 100% errors
* Reading from rom gives always #00 from #C000 - #FFFF
* Reading from #Axxx also reads #00
* Memtest on #BFFE/#BFFF succeeds
So I wonder ... can ICE-T65 test the video ram in a normal Atom? I used it only in Godil configurations. And, does my eeprom hold any data? How to check without appropriate hardware?
BTW ... the answer to the question of the ramrod is probably a combination of the answers 2 and 3. When I drink beer my spell checker starts failing

FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
Hi Roland,
damned ...... someone has discovered my other hobby .....
Here is an image of the ramrod file I burned for you, there is data at #14000.
The AtoMMC version of #C/D/E/F is located at #10000-#13ffff and is default for the RAMROM board.
The DOSROM version of #C/D/E/F is located at #14000-#17fff.
Greetings
Kees
damned ...... someone has discovered my other hobby .....

Here is an image of the ramrod file I burned for you, there is data at #14000.
The AtoMMC version of #C/D/E/F is located at #10000-#13ffff and is default for the RAMROM board.
The DOSROM version of #C/D/E/F is located at #14000-#17fff.
Greetings
Kees
- Attachments
-
- rl160709.zip
- (56.15 KiB) Downloaded 36 times
Last edited by oss003 on Sun Jul 31, 2016 8:30 pm, edited 2 times in total.
Re: YARRB
Give me five minutes, and I'll try it.roland wrote: So I wonder ... can ICE-T65 test the video ram in a normal Atom? I used it only in Godil configurations. And, does my eeprom hold any data? How to check without appropriate hardware?
Dave
Re: YARRB



Rom issue solved. I discovered a small design mistake. To prevent the eeprom from accidentally being erased during test (you never know....) I removed the write enable jumper. But that makes the input pin 31 floating. And it turns out that if this pin is floating, the eeprom cannot be read. I had to put in a pull up resistor to pin 31

I don't know why I got the idea of placing this jumper back but it solved an issue.
I don't hear any beeps when I press CTRL+G and I don't see any picture. I'll connect a monitor to the Atom tomorrow, enough for today

FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
Looks impressive doesn't it?
FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
My original Atom still uses 2114s for video RAM, and has Phill's RamRom board for everything else.roland wrote: So I wonder ... can ICE-T65 test the video ram in a normal Atom? I used it only in Godil configurations. And, does my eeprom hold any data? How to check without appropriate hardware?
At 1MHz, ICE-T65 tests on normal RAM and video RAM both pass.
At 1.79MHz, ICE-T65 tests on normal RAM pass, but tests on video RAM fail in some regions (e.g. 9000-97FF). This does suggest there is something slightly dodgy about the way the ICE-T65 is doing it's memory tests.
What are you using for video RAM?
If you read Kees's post carefully, you'll see that the "standard" 128KB ROM image has the DOS OS ROM set at 0x14000 and the AtoMMC OS ROM set at 0x10000.roland wrote: I don't hear any beeps when I press CTRL+G and I don't see any picture. I'll connect a monitor to the Atom tomorrow, enough for todayO, it seems that the ICE-T is looping somewhere in #Exxx. It might help if I connect an AtoMMC.
I seem to remember if you try to run the DOS OS Image without the hardware it hangs. This might be what's happening.
Dave
Re: YARRB
Very nice, apart from the blue case which clashes dreadfullyroland wrote: Looks impressive doesn't it?

In fact, in an 1.79MHz Atom the ICE-T65 seems to have real problems with the Video RAM.hoglet wrote: At 1.79MHz, ICE-T65 tests on normal RAM pass, but tests on video RAM fail in some regions (e.g. 9000-97FF). This does suggest there is something slightly dodgy about the way the ICE-T65 is doing it's memory tests.
I'll need to hook up the scope check the timing on the video RAM.
The 2114's are 300ns, so things should work at 1.79MHz (560ns cycle), but clearly they don't!
Dave
Re: YARRB
When I read the image at Exxx It turns out to be the AtoMMC rom. And it looks like it's waiting for the a signal from the pic.hoglet wrote: If you read Kees's post carefully, you'll see that the "standard" 128KB ROM image has the DOS OS ROM set at 0x14000 and the AtoMMC OS ROM set at 0x10000.
I seem to remember if you try to run the DOS OS Image without the hardware it hangs. This might be what's happening.
Dave
My video memory is a HM6264LP-15. The Godil is running @ 1MHz.
And yes, the blue case clashes enormously with the green pcb. Where can I order a blue pcb

FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
The only thing I know will hang AtoMMC on start up is using the PIC AtoMMC ROM on the AVR hardware, or visa versa.roland wrote: When I read the image at Exxx It turns out to be the AtoMMC rom. And it looks like it's waiting for the a signal from the pic.
Is 128KB ROM image working in Atomulator?
Dave
Re: YARRB
I will test it in Atomulator tomorrow. And I have to figure out why I get the MMC rom as this is not according to the specs. I might have swapped two address lines somewhere.
FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
IIRC the Atom also hangs while booting with the MMC-ROM and the MMC interface is disconnected.
You can try CTRL-BRK.
Greetings
Kees
You can try CTRL-BRK.
Greetings
Kees
Re: YARRB
Hi Kees,
Before I read your message I thought about this. And I couldn't resist to test this before I got to work. And yes! If I press CTRL+BREAK and then CTRL+G I hear the good old sound of a simple beep
So yes, if no AtoMMC is connected the Atom will wait for it. This evening I will connect a monitor to the Atom to see what the screen does. I expect that it will work quite well now.
Can't wait.....
Greetings,
Roland
Before I read your message I thought about this. And I couldn't resist to test this before I got to work. And yes! If I press CTRL+BREAK and then CTRL+G I hear the good old sound of a simple beep

So yes, if no AtoMMC is connected the Atom will wait for it. This evening I will connect a monitor to the Atom to see what the screen does. I expect that it will work quite well now.
Can't wait.....
Greetings,
Roland
FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
Great to see this moving forward Roland. Well done!
Dave
Dave
Re: YARRB
Nice job ....
Greetings
Kees


Greetings
Kees
Re: YARRB
Well, if it is completely not working, it has to be something small
To be honest, it was Hoglet's remark to check the input clock that got me on the road. I was expecting a 1 MHz clock but it turned out to be 250 kHz. It surprises me that this low clock rate also influences the Godil.
I have two ideas for a MK2 board (if it ever will come):
1. Add a pull up resistor to pin 31 of the EEPROM
2. Replace the 74LS133 by a 74LS30
The CPLD gets A8 ... A15 as input lines so it can detect #BF. The lower seven bits can then be detected by an 8-input nand (74LS30). And this chip has to be removed from the Atom main board, so it is directly available. However, it is a very small change to make the current board suitable for the 74LS30: cut A13 next to pin 15 by drilling the via next to the pin and connect pin 16 to pin 15 with a big drop of tin. This small mod will leave out A1 so the registers in the CPLD are also visible on #BFFC/#BFFD. But this is a feature that was intended because there is a jumper to exclude A1 from the #BFFF selection.
I will design the final VHDL to be compatible with this mod.

To be honest, it was Hoglet's remark to check the input clock that got me on the road. I was expecting a 1 MHz clock but it turned out to be 250 kHz. It surprises me that this low clock rate also influences the Godil.
I have two ideas for a MK2 board (if it ever will come):
1. Add a pull up resistor to pin 31 of the EEPROM
2. Replace the 74LS133 by a 74LS30
The CPLD gets A8 ... A15 as input lines so it can detect #BF. The lower seven bits can then be detected by an 8-input nand (74LS30). And this chip has to be removed from the Atom main board, so it is directly available. However, it is a very small change to make the current board suitable for the 74LS30: cut A13 next to pin 15 by drilling the via next to the pin and connect pin 16 to pin 15 with a big drop of tin. This small mod will leave out A1 so the registers in the CPLD are also visible on #BFFC/#BFFD. But this is a feature that was intended because there is a jumper to exclude A1 from the #BFFF selection.
I will design the final VHDL to be compatible with this mod.
FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
Hi Roland,
This afternoon I investigated why the ICE-T65 video RAM test was failing on my original Atom in some banks when clocked at 1.79MHz.
Here's what I discovered:
- the failure seems to be unreliable reads, rather than unreliable writes, as a crc on the data written by the test kept changing
- at 1.79MHz the cycle time is 560ns
- the Atom's (IC27/28) video buffers are only enabled when Phi2 is high (i.e. the second half of the clock cycle)
- this means the video RAM read needs to take less than 280ns
- actually, quite a bit less, because of delays through IC9, IC8 and IC27/28 in enabling the address (20ns + 5ns + 15ns)
- those banks that contained Mitsubishi M5L2114LP-3 were failing. The datasheet says the access time is 300ns.
- those banks that contained NEC uPD2114LC-3 were passing. The datasheet says the access time is 200ns.
- so basically with the Mitsubishi -3 2114's the timing is marginal at best
- there was a small mistake in the ICE-T65 that meant the read sampling point was ~40ns before the falling edge of Phi2
I've fixed the small issue in ICE-T65, and tested in both the Atom and the Beeb.
In the Atom the Video RAM tests now pass in all banks.
Here's an updated .mcs file for ICE-T65: You're using much faster video RAM (150ns) and seeing failures at 1MHz so I don't think your problem can be the same.
Maybe you could try to determine if the writes are sometimes failing in your case. For example, run the random memory test, then once that finishes, run the crc command over the video RAM a few times. If this shows a consistent value, it means that reads are stable, so the problem must be with writes.
Dave
This afternoon I investigated why the ICE-T65 video RAM test was failing on my original Atom in some banks when clocked at 1.79MHz.
Here's what I discovered:
- the failure seems to be unreliable reads, rather than unreliable writes, as a crc on the data written by the test kept changing
- at 1.79MHz the cycle time is 560ns
- the Atom's (IC27/28) video buffers are only enabled when Phi2 is high (i.e. the second half of the clock cycle)
- this means the video RAM read needs to take less than 280ns
- actually, quite a bit less, because of delays through IC9, IC8 and IC27/28 in enabling the address (20ns + 5ns + 15ns)
- those banks that contained Mitsubishi M5L2114LP-3 were failing. The datasheet says the access time is 300ns.
- those banks that contained NEC uPD2114LC-3 were passing. The datasheet says the access time is 200ns.
- so basically with the Mitsubishi -3 2114's the timing is marginal at best
- there was a small mistake in the ICE-T65 that meant the read sampling point was ~40ns before the falling edge of Phi2

I've fixed the small issue in ICE-T65, and tested in both the Atom and the Beeb.
In the Atom the Video RAM tests now pass in all banks.
Here's an updated .mcs file for ICE-T65: You're using much faster video RAM (150ns) and seeing failures at 1MHz so I don't think your problem can be the same.
Maybe you could try to determine if the writes are sometimes failing in your case. For example, run the random memory test, then once that finishes, run the crc command over the video RAM a few times. If this shows a consistent value, it means that reads are stable, so the problem must be with writes.
Dave
Re: YARRB
I did run five test on my video memory, they all passed. I also did a test on all the ram, it also passed
Time to put 4 MHz equipment in the Atom
Code: Select all
>> test 0 9fff
Memory test: Fixed 55: passed
Memory test: Fixed AA: passed
Memory test: Fixed FF: passed
Memory test: Fixed 00: passed
Memory test: Checkerboard: passed
Memory test: Inverse checkerboard: passed
Memory test: Address pattern: passed
Memory test: Inverse address pattern: passed
Memory test: Random: passed
Memory test: Random: passed
Memory test: Random: passed

FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
You're right, it's a lot easier with a monitor attached ......
Go and activate warp mode captain ....
Greetings
Kees

Go and activate warp mode captain ....
Greetings
Kees
Re: YARRB
This confused me a bit, it doesn't match anything. I reviewed the drawing, the PCB, the VHDL, the ucf but I couldn't find the error. How on earth can I read the AtoMMC rom in this configuration. Until I came up with a horrible thought that I first denied to myself: can Hoglet be wronghoglet wrote: One last thought: What's the contents of your ROM? It looks like on power up Atom addresses 0xC000-0xFFFF will be mapped to ROM address 0x14000-0x17FFF. Is that what you intended?

And yes, the addresses 0xC000-0xFFFF are not mapped to 0x14000-0x17FFF.
When #C000 - #FFFF is addressed, RA16 is 1, RA15 is always 0, RA14 is also 0 when this area is addressed:
Code: Select all
if (A15 = '0' and A14 = '1') or (A15 = '1' and A14 = '0' and A13 = '1' and A12 = '0' and BS2 = '1') then
RA14 <= '1';
else
RA14 <= '0';
end if;
For now, the board is working fine. RAM tests work, Branquar is working, AtoMMC is fine. I can play some games. Unfortunately Chuckie Egg hangs when I eat an egg but I cannot point to a hardware failure.
1-2-4 MHz is also kind of working. When I switch to 2 or 4 MHz then the Atom hangs, even if I do ?#208=?#208+3 to disable the printer driver. But in an assembly program it works fine.
I think it's time to work out the final design of the CPLD.
Shall I start shipping the boards to the UK?
Greetings,
Roland
FPGAtom: much better than Atom2k15 which was even better than the real thing.
MAN WOMAN
MAN WOMAN

Re: YARRB
roland wrote: Until I came up with a horrible thought that I first denied to myself: can Hoglet be wrong![]()





This happens much more often than you might imagine.
In fact, if you speak to Mrs Hoglet, she will tell you that I'm actually wrong most of the time

Especially anything to do with loading the dish washer, which is especially tricky to do correctly....

Yes please!roland wrote: Shall I start shipping the boards to the UK?
Dave
Re: YARRB
Hi Roland,
Greetings
Kees
Could it be that #0Axx is reserved for the diskcontroller instead of RAM?roland wrote:For now, the board is working fine. RAM tests work, Branquar is working, AtoMMC is fine. I can play some games. Unfortunately Chuckie Egg hangs when I eat an egg but I cannot point to a hardware failure.
Greetings
Kees
Re: YARRB
The RAM Test did seem to be passing on that page earlier.oss003 wrote: Could it be that #0Axx is reserved for the diskcontroller instead of RAM?
Is Chuckie Egg failing with the ICE-T65 or with a real 6502?
Dave
Re: YARRB
Did you fix this bug?roland wrote: Unfortunately Chuckie Egg hangs when I eat an egg but I cannot point to a hardware failure.
Code: Select all
-- read registers
DD <= regBFFE when (nBFFX = '0' and RW = '1' and RS = '0') else
regBFFF when (nBFFX = '0' and RW = '1' and RS = '1') else
(others => 'Z');
Dave