YARRB [SOLD OUT]

[TheCorfiot]

I wouldnt mind a board if you have a spare please

[roland]

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

[roland]

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 ....

yarrb.txt

The current vhdl in the CPLD

(5.05 KiB) Downloaded 43 times

[hoglet]

Hi Roland,

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');

should be:

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');

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

[roland]

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.

[1024MAK]

ramrod

See here
Wrong hobby me thinks

Good luck with the bug hunting

Mark

[roland]

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.

[roland]

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

[oss003]

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

[hoglet]

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?

Give me five minutes, and I'll try it.

Dave

[roland]

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 O, it seems that the ICE-T is looping somewhere in #Exxx. It might help if I connect an AtoMMC.

[roland]

Looks impressive doesn't it?

[hoglet]

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?

My original Atom still uses 2114s for video RAM, and has Phill's RamRom board for everything else.

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?

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 O, it seems that the ICE-T is looping somewhere in #Exxx. It might help if I connect an AtoMMC.

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

[hoglet]

Looks impressive doesn't it?

Very nice, apart from the blue case which clashes dreadfully

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.

In fact, in an 1.79MHz Atom the ICE-T65 seems to have real problems with the Video RAM.

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

[roland]

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

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.

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

[hoglet]

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.

The only thing I know will hang AtoMMC on start up is using the PIC AtoMMC ROM on the AVR hardware, or visa versa.

Is 128KB ROM image working in Atomulator?

Dave

[roland]

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.

[oss003]

IIRC the Atom also hangs while booting with the MMC-ROM and the MMC interface is disconnected.

You can try CTRL-BRK.

Greetings
Kees

[roland]

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

[hoglet]

Great to see this moving forward Roland. Well done!

Dave

[oss003]

Nice job ....

Greetings
Kees

[roland]

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.

74ls133-to-30.jpg (18.41 KiB) Viewed 1658 times

[hoglet]

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:

avr6502cpu.zip

(133.01 KiB) Downloaded 28 times

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

[roland]

I did run five test on my video memory, they all passed. I also did a test on all the ram, it also passed

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     

Time to put 4 MHz equipment in the Atom

[oss003]

You're right, it's a lot easier with a monitor attached ......

Go and activate warp mode captain ....

Greetings
Kees

[roland]

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?

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 wrong

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;

RA13 and and RA12 "follow" A13 and A12. So the mapping of the rom is at 0x10000-0x13FFF and that's where the AtoMMC code resist.

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

[hoglet]

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....

Shall I start shipping the boards to the UK?

Yes please!

Dave

[oss003]

Hi Roland,

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.

Could it be that #0Axx is reserved for the diskcontroller instead of RAM?

Greetings
Kees

[hoglet]

Could it be that #0Axx is reserved for the diskcontroller instead of RAM?

The RAM Test did seem to be passing on that page earlier.

Is Chuckie Egg failing with the ICE-T65 or with a real 6502?

Dave

[hoglet]

Unfortunately Chuckie Egg hangs when I eat an egg but I cannot point to a hardware failure.

Did you fix this bug?

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');

If #3FFE/F were getting messed up, that might affect Chuckie Egg.

Dave