Jump to content
foft

Potential new hardware

Recommended Posts

Totally untested but try experimentwait.sof... Modified the vhdl to add an extra wait state and rebuilt.

Just gave it a try, but couldn't get it to start at all. At one time, after doing a hard reset after powerup, I saw some random screen data (looked like a random display list) for a fraction of a second, then it vanished.

 

Could you maybe re-upload the very first sof you posted so I could give that one a try?

 

so long,

 

Hias

Share this post


Link to post
Share on other sites

Oh shame:( Will have to wait until I'm back at a de1.

 

The de1 directory is public and the old sof files are there.

 

I'm reading about the ad724 for now. Rgb to pal/ntsc.

Share this post


Link to post
Share on other sites

@foft: Sorry, I've been away from the DE1 for some days! Back to testing.

I've tried the new experiment with the added delay and I get the same results: black screen. No errors. Monitors detect 576i video signal ok via the VGA-SCART connector, but I can't see anything on screen.

 

Could you add some kind of error message in case ATARIOS and BASIC roms aren't well flashed? Like making an error code appear on the 7-segments display for example. First experimental version worked (at least it allowed some basic playing), so the roms were ok, but I reflashed them several times since, with an unofficial Linux tool as I told you (I don't have a Windows machine).

 

My board has:

-Flash RAM: "SPANSION" S29AL032D70TFIO4

-SDRAM: "ZENTEL" A2V64S40CTP

 

 

My monitors all do 50HZ as I use the Minimig in PAL mode, Chameleon in PAL 50HZ mode and MSX in 1ChipMSX PAL mode, both via SCART and VGA.

Share this post


Link to post
Share on other sites

Thanks Vanfanel. The good news is you have the same 70ns flash as me, so surprised it doesn't work for you. Which sram chip do you have? The earlier sof files are still there so if the rom flashing is right they will still work. Agree error checking would be a good use of the hex digits.

 

I expect the experimentwait.sof is broken, it was completely untested (older quartus version + code changes done via vnc from iPhone!). Did you check the latest experiment.sof with all switches down?

 

When I'm back we can work to figure out the cause. e.g. use internal ram/rom via switches to isolate external chips.

 

In the meantime I need to work out how to model the sram and flash in timequest properly...

Edited by foft

Share this post


Link to post
Share on other sites
The de1 directory is public and the old sof files are there.

Ah, thanks a lot!

 

Did some quick tests: 20130626 wouldn't boot at all, 20130618 did (most of the time) come up with a graphics 0 screen if I set reset before uploading the sof and then switched reset off.

 

Also did a quick test with minimig to check my DE1, worked fine so far (but I think minimig doesn't use the flash).

 

I'm reading about the ad724 for now. Rgb to pal/ntsc.

Also stumbled across this one. Looks nice and requires almost no external parts (even works with a standard 4.43MHz crystal, AD725 needs a 17.72MHz oscillator). RS and farnell both have these on stock, guess I'll have to place an order :)

 

so long,

 

Hias

Share this post


Link to post
Share on other sites

Since I'm a linux-only user, I used the DE1 control panel replacement (wich is a command-line program) that can be found here:

ftp://ftp.zytor.com/pub/fpga/de1flash

I'm also using de1flash (I'm a Linux user, too) and it seems to work just great. Programmed atarixl.rom and ataribas.rom with it, and despite my issues with the core the ROMs don't seem to be a problem. Also tried the atariroms.bin from foft's website (flashed it to address 0) and it worked.

 

BTW: Not sure about this though:

Then we can write the ROM files to flash with the script called de1flash.tcl, wich is also included with the cp replacement download file :

./quartus_stp -t de1flash.tcl write ~/ATARI/[email protected]

 

Did you really progam atariosb.rom (I used atarixl.rom), if yes what size is the ROM? atarixl.rom is 16k ($C000-$FFFF in Atari space, with selftest @$D000), atariosa.rom and atariosb.rom are usually 10k files ($D800-$FFFF in Atari space - $C000-$CFFF is unused in osa/osb, and there's no selftest. Only mathpack at $D800-$DFFF and OS ROM at $E000-$FFFF - usually they are combined into a 10k file for emulators). If you have a 10k file you need to adjust the flash address and program it at @0x1800:

 

./quartus_stp -t de1flash.tcl write ~/ATARI/[email protected]

 

BTW: Though I'm a Linux user I thought it could save me some time if I did my first experiments on an old Windows XP box. What a big mistake, this cost me a whole day downloading and installing various quartus versions, but I couldn't get the DE1 control panel to work at all. It always complained that Quartus wasn't installed. I found several reports of this issue on the web, but none of the suggestions worked (of course Quartus was installed in the default location, and it worked fine - even uploaded the control panel sof using the quartus programmer, but to no avail, the damned DE1 control panel would still complain and refuse to start).

 

Then I ditched the idea of using the Windows DE1 control panel and had quartus programmer and de1flash working on my Linux box within a few minutes...

 

Thanks a lot for mentioning de1flash, otherwise I would still be struggling with this crappy windows software!

 

so long,

 

Hias

Share this post


Link to post
Share on other sites

Pleased to hear one of the older ones works better for you Hias. Pretty sure it's just a timing issue that will be trivial to resolve when I'm back.

 

Good spot on the osb. Yes I expect an xl/xe rom. The 0x0000 in the flash gets mapped to 0xc000 in Atari memory. It definitely needs a vector at 0xFFFE/F (0x3ffe in flash) to do anything useful:)

 

Hias, I tried to build my untested 'longer waitstate' version in Quartus 13 too, in case it failed due to downgrade from 12 to an earlier version! Unlikely though...

 

On another note I'm looking to build a pcb for this, with an fpga, ram and Atari connectors. Is anyone reading this able to help with:

I) Source for sio sockets? Pretty sure I got a new one on an order from Atarimax so someone is making them!

Ii) pcb design review?

Edited by foft

Share this post


Link to post
Share on other sites

@foft: got it to work again. I totally deleted flash memory and re-wrote using the atariroms.bin file.

How did you load Alternate Reality intro? There seems to be no support for disk images or carts on the SD, minimig-style.

I think I will go crazy if I can sing along the intro lyrics or AR on the DE1 :D

 

Oops, I just read you used a GPIO to disk scheme. Then I'm out of luck until you implement some way to load disks from SD.

 

But there's something special about the Atari 800: just looking at the READY prompt and trying some basic tricks I still remember is fun and being an FPGA implementation it retains the elegance and feeling of the original computer.

Edited by vanfanel

Share this post


Link to post
Share on other sites

@vanfanel: Excellent:)

 

If you don't want to solder those two wires on you can still load from cas images! Use a straight wired rs232 cable and aspeqt. That said I don't think AR was available on cassette...

 

Any views of the best way to implement the sd card? I'll need a CPU to process the file system then I could either host atr images on the sio bus (pokey to pokey) or... Patch the os and directly copy into ram. Hmmmm. I guess car images may be easiest to start with.

Share this post


Link to post
Share on other sites

@foft: The latest Mimimig core on the DE1 (available here: https://github.com/rkrajnc/minimig-de1) used to have a secondary 68000 softcore for the filesystem processing.

However, maybe you should take a look at the ZCPU core, since MMRobinsonb5 is experimenting with it for similar purposes and it's much smaller and simpler that a full 68000 softcore. http://retroramblings.net/

Share this post


Link to post
Share on other sites

ZPU looks great, tiny footprint and with GCC support.

Share this post


Link to post
Share on other sites

@foft: MMRobinsonb5 has even published a filesystem management example for loading JPG images using the ZPU, not sure if you saw it. It's on the Space Harrier image entry on his blog: http://retroramblings.net/?p=564

Of couse he has published the code. You can check it there. He's a very cool guy :)

Share this post


Link to post
Share on other sites

I know nothing about FPGA programming but this seems like incredible progress in such a short time. It would be wonderful to have new 8-bit hardware.

 

Paul

  • Like 2

Share this post


Link to post
Share on other sites

I've used Xilinx FPGA's in the past to create a GPU for a project at work using licensed IP modules and always thought that it would be awesome to create an Atari 800 with one of these devices someday. Foft - You're awesome, man!

Edited by atx4us

Share this post


Link to post
Share on other sites

Reasonable price for those from Poland: http://kamami.pl/ind...roductID=177285

 

For students even less price...

 

Anyway. I wish you VERY VERY MUCH to drive this project to state ">=99%" compatibility in standard emulation mode.

In turbo mode the compatibility is not so important in HW, with CPU exception, which should achieve 100%, but this is easy for you, as I see :)

 

I'd prefer to have an emulation of "bunch of cartridge slots", let's say 4 or 8 or even more, of type: atarimaxflash, Sic!, OSS.

 

--------------------------

On the other hand I see:

- zx on de1

- minimig (68k only)

- atari st works in progress

- many cpu cores available

 

So I think this is very universal device, get, upload and voilla!

Edited by jhusak

Share this post


Link to post
Share on other sites

I'm back in town and working on this again...

 

First the bad news: The untested 'slow ROM' builds I did last month work on my board. The extra wait state is also present.

 

Next release end of next week. Features to look forward to: scandoubler, NTSC/PAL switch, fix for the 'new DE1 problems', running again real 1050 + 1010 and higher compatibility (target - 7 more acid 800 passes!).

 

Did anyone try out some software beyond basic/self test?

Share this post


Link to post
Share on other sites

Anyway. I wish you VERY VERY MUCH to drive this project to state ">=99%" compatibility in standard emulation mode.

In turbo mode the compatibility is not so important in HW, with CPU exception, which should achieve 100%, but this is easy for you, as I see :)

 

I'd prefer to have an emulation of "bunch of cartridge slots", let's say 4 or 8 or even more, of type: atarimaxflash, Sic!, OSS.

Yes getting to 99% is my target for this month. Wish me luck:)

 

Noted your cart suggestion. I might build something that sits on the sio bus and in cart memory space then release the c++ so it can be extended to support more formats. Working on the sd access is next month probably.

Edited by foft

Share this post


Link to post
Share on other sites

Working on the sd access is next month probably.

 

May I suggest a higher priority for SD card access? It would open the door to massive software testing for those of us without floppy drives and disks. It would help a lot to identify failing titles and you could rise compatibility much faster! :)

Share this post


Link to post
Share on other sites

 

 

May I suggest a higher priority for SD card access? It would open the door to massive software testing for those of us without floppy drives and disks. It would help a lot to identify failing titles and you could rise compatibility much faster! :)

 

Of course you may suggest it:) To be honest though compatibility is too low right now to fix individual game issues. For now I'm working through acid800. After that testing individual titles will be helpful. ie once its useful to test thoroughly if will be high priority.

Share this post


Link to post
Share on other sites

run away from t65 core if you can

I am planning to make my own CPU if I have time.

 

Know any good vhdl 6502 cores?

 

I haven't looked at t65 code much except fixing one bug. Why do you say this?

Share this post


Link to post
Share on other sites

because i've looked into the code ;)

no, seriously it looks suspicious, and not very elegant, but that wouldn't matter if it worked reliable

there is another core related to fpga commodore project that is very vell written and cycle exact - the only thing missing is halt signal, but i guess you already found your way around this

you can't use it in commercial product, and really should contact the author, but i think it is worth to give it a go before digging somewhere else

Share this post


Link to post
Share on other sites

there is another core related to fpga commodore project that is very vell written and cycle exact

Thanks. Which commodore project do you mean?

 

This thread discusses 10 versions.

 

http://forum.6502.org/viewtopic.php?f=10&t=1673

 

+ this one:

http://www.stepinfusion.com/projects/pet2001fpga/

 

I'm thinking Jens' looks good though it takes more luts. gpl so would need to release source - but I probably will...

 

Edit:Artlet's core looks great, though its verilog - mixing may be an issue. Also the 2 cycle reads may cause some compatibility problems. Nice and small and fast though!

Edited by foft

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...