Novatron
Forum rules
Be nice. No drama.
Be nice. No drama.
Re: Novatron
The controller works when the monitor isn't plugged in (verified by audio not video obviously!). Plugging in the monitor or even putting the oscilloscope probe on pin 11 and 12 of the 595 causes the issue with the bits being transposed. I wasn't able to "see" what was happening, but it seems the issue is caused by the clock edge to the 595 being too slow.
I can't really speed up the clock edge, but I can slow down the PULSE to the controller. I have a spare flip-flop and ran the HSYNC through that before sending it to the controller. This fixes the issue and the button mapping is now working when the monitor is plugged in.
I can't really speed up the clock edge, but I can slow down the PULSE to the controller. I have a spare flip-flop and ran the HSYNC through that before sending it to the controller. This fixes the issue and the button mapping is now working when the monitor is plugged in.
Re: Novatron
Good to hear you got it working so quickly. The Menlo FPGA code had a similar issue for me but I fixed it by sampling on a falling edge and delaying PULSE by 80ns and it's been consistently working with 4021/165 based controllers. He/She never reported it as an issue, so I'm guessing that whatever controller was in use had slightly different timing. Basically you were seeing "bit n" from the last shift and the first 7 bits of the currently latched button state because of mismatch between when the controller PISO shifts out the bits and when the Gigatron SIPO samples them.
- Attachments
-
- sync timing.JPG (19.03 KiB) Viewed 1734 times
Re: Novatron
I just received the updated board with the final fixes. Gamepad is working and also works with the ATtiny85/keyboard plugged in. I fixed the issues with the SPI and have the SD card working! I've only just finished the build and did some quick tests. Card boot is running, but it's not finding the System.gt1 file. I'm using the dev ROM and system.gt1 file from the binaries directory. This is what I have in the card's root directory:
Code: Select all
% ls /Volumes/GIGATRON
CardBoot.gt1 Reset.gt1 System.gt1
Re: Novatron
The hex number that is displayed after "Vol.ID" is the logical sector size, as found at offset 0xB in the first sector of the FAT partition. On the Gigatron, this number should be 0x200 (512 bytes/sector). In addition the only legal values there are powers of two. Therefore, if it really were 0x101, then the FAT filesystem would be invalid.
To me this means that either we got the wrong data or we got the wrong sector. I am inclined to believe we got the wrong sector because it seems that we were able to find the MBR in sector zero. One common way to get the wrong sector is to misidentify the card type because the read command wants a byte offset on SDSC cards (max 2GB) and a physical sector number on SDHD/SDXC (sizes from 2GB to 2TB). The "CardType 04" means that we have detected the latter (SDHD or SDXC). Is this correct?
Could you send a compressed version of the first megabyte of your sd card (using dd if=/dev/sdX bs=1m count=1 of=sd.bin on unix for instance). I would be able to trace cardboot and make better suggestions.
p.s. - There is no need to have cardboot.gt1 on the sd card. It lives inside the dev rom.
To me this means that either we got the wrong data or we got the wrong sector. I am inclined to believe we got the wrong sector because it seems that we were able to find the MBR in sector zero. One common way to get the wrong sector is to misidentify the card type because the read command wants a byte offset on SDSC cards (max 2GB) and a physical sector number on SDHD/SDXC (sizes from 2GB to 2TB). The "CardType 04" means that we have detected the latter (SDHD or SDXC). Is this correct?
Could you send a compressed version of the first megabyte of your sd card (using dd if=/dev/sdX bs=1m count=1 of=sd.bin on unix for instance). I would be able to trace cardboot and make better suggestions.
p.s. - There is no need to have cardboot.gt1 on the sd card. It lives inside the dev rom.
Re: Novatron
Thanks @lb3361. I don't have a lot of SD Cards and this was the only one I could find at short notice. Picture attached of the card and format on Mac. I had to zip the sd.bin file so it would attach (it just contains system.gt1 right now):
Re: Novatron
This one is different from the one you were testing above because It has no partition table and only contains a FAT32 filesystem.
I suggest debugging the novatron with this proven one: https://github.com/lb3361/gigatron-rom/ ... sd.vhd.bz2
It should be 64M large after executing bunzip2. It only contains system.gt1 and mandelbrot.gt1.
Just dd it over you sd card which is large enough.
Meanwhile I have made some improvements to CardBoot in order to make it work better with certain partitionless sd cards. See https://github.com/lb3361/gigatron-os/c ... 7cd951e4f5. I made sure that the dev.rom contained in 'binaries' has this new version.
- Leon
I suggest debugging the novatron with this proven one: https://github.com/lb3361/gigatron-rom/ ... sd.vhd.bz2
It should be 64M large after executing bunzip2. It only contains system.gt1 and mandelbrot.gt1.
Just dd it over you sd card which is large enough.
Meanwhile I have made some improvements to CardBoot in order to make it work better with certain partitionless sd cards. See https://github.com/lb3361/gigatron-os/c ... 7cd951e4f5. I made sure that the dev.rom contained in 'binaries' has this new version.
- Leon
Re: Novatron
I'm still seeing the same issue. I unzipped the file to the correct 64M size and then transferred it using dd. Once complete the card wasn't recognizable on my Mac or Windows machines, but showed the same error on the Novatron. I'll see if I can get some different cards and try those.
Re: Novatron
Something is wrong. It should be recognizable by both Mac and Windows machines. Did you dd onto /dev/sda or /dev/sda1. Here is exactly what I am doing (my sd card slot appears as /dev/sda). I am also attaching the file sd.vhd.bz2 from https://github.com/lb3361/gigatron-rom/ ... ntrib/at67 because there may be several versions floating around.
Also try the new dev.rom from https://github.com/lb3361/gigatron-os/t ... 1/binaries. It fixes one error that could have prevented your earlier sd card from working.
Code: Select all
## uncompress sd card image
$ bunzip2 -c sd.vhd.bz2 > sd.vhd
$ ls -lh sd.vhd
-rw-rw-r-- 1 leonb leonb 64M Sep 9 18:06 sd.vhd
## insert sd card and make sure it is not mounted
$ sudo umount /dev/sda1 ## to make sure the
$ sudo umount /dev/sda
## copy sd image to sd card
$ sudo dd if=sd.vhd bs=1M of=/dev/sda
64+0 records in
64+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 3.44269 s, 19.5 MB/s
$ sudo eject /dev/sda
## remove and reinsert sd card
## on my ubuntu machine, it gets mounted automatically
$ df -h | grep sda
/dev/sda1 63M 28K 63M 1% /media/....
$ ls -l /media/....
total 26
-rw-r--r-- 1 lb3361 lb3361 1250 Sep 8 11:58 Mandelbrot.gt1
-rw-r--r-- 1 lb3361 lb3361 24499 Sep 8 11:58 System.gt1
- Attachments
-
- sd.vhd.bz2
- (13.13 KiB) Downloaded 97 times
Re: Novatron
There was a bit of a trick needed to dd the image from MacOS (/dev/rdisk2). I can now copy the image and mount it correctly. The new ROM version fixes the "Vol.ID 0101" error, but I'm now getting "FAT32 FAILED". I get this error with both a clean FAT32 formatted drive and the sd.vhd image. The master boot record is OK on the clean card, but the sd.vhd image displays an MBR error as well.
. .
I tried to use VirtualBox to dd the image from Ubuntu. That didn't seem to work, so I might investigate further to see if I can figure that out. I might have a spare laptop that can install Ubuntu natively.
. .
I tried to use VirtualBox to dd the image from Ubuntu. That didn't seem to work, so I might investigate further to see if I can figure that out. I might have a spare laptop that can install Ubuntu natively.
Re: Novatron
The sd.vhd image has a proper MBR with a single type 0c partition. Once copied to the sd card, is it recognized by macos or windows? If yes this means that the sd card imaging worked. When booting the gigatron, this image should display "MBR 0C OK". But you get "MBR 0D FAILED". I am starting to suspect that the data read is corrupted. This is consistent with you receiving a MBR error on a freshly formatted FAT32 sd card that has a proper master boot record.
Here is a dev.rom with a debug version of cardboot. It is slower because it does not blank the screen (but you don't care) and it shows the sector buffer in the last lines of the screen (below the line of white pixels at $7c00). So when the boot fails, you should be able to see the bytes at offsets [0x00-0xbf] and [0x100-0x1bf] on the following two scanlines. Turns out that the useful things in the MBR are beyond position 0x1c0. With the provided sd.vhd, these two scanlines should only show zeroes (i.e. black pixels). Then you can try to write things in the first block of the sd card and see if you can see them at the bottom of the screen.
This new version also contains a difference. It prints "MBR FAILED" if the sector 0 does not contain the $aa55 signature at address 0x1fe, something that would surely indicate a garbled read. It is displaying "MBR xx FAILED" if the signature is present but the partition type xx is not 0b or 0c.
Hope it helps.
Here is a dev.rom with a debug version of cardboot. It is slower because it does not blank the screen (but you don't care) and it shows the sector buffer in the last lines of the screen (below the line of white pixels at $7c00). So when the boot fails, you should be able to see the bytes at offsets [0x00-0xbf] and [0x100-0x1bf] on the following two scanlines. Turns out that the useful things in the MBR are beyond position 0x1c0. With the provided sd.vhd, these two scanlines should only show zeroes (i.e. black pixels). Then you can try to write things in the first block of the sd card and see if you can see them at the bottom of the screen.
This new version also contains a difference. It prints "MBR FAILED" if the sector 0 does not contain the $aa55 signature at address 0x1fe, something that would surely indicate a garbled read. It is displaying "MBR xx FAILED" if the signature is present but the partition type xx is not 0b or 0c.
Hope it helps.
- Attachments
-
- dev.rom
- (128 KiB) Downloaded 97 times