29.05.2020 Hm the last days haven't been very productive. I build in one bug after another. The hd implementation worked alot better. Mostly with smaller fixes it worked fine. But this meh was a real pain in the ass. But now it's working again.
I was working on something I'm shifting since monthes. The old version was only able to work on 4mb because of the direct direct addresses and stuff. That was quite a bit of work.
Also the cartridge needs only as much memory as it really needs. Before it has been about 240kb. Yeah 240kb because of lazyness in calulation ;) Now it's 20kb.
Also started to include Tin's and ggn's new bugaboo (which needed also some changes to be flexible). But Bugaboo is not fully tested yet.
Anyway I'll do in the next days.

I downgraded my STE to 2mb to test and it worked fine now. This is cool.

Besides I'm using now the system 8x8 font to save some cartridge space. I want to include later a small crash handler which can be installed by using the cartridge library which shows the call stack with symbols. Just did a short test a disassembler would fit too. But anyway a future feature.

Used the cartridge to code a bit yesterday. I was working on an overscan with sid. Nice coding without touching the Atari ;)

23.05.2020 Having a weekend off from my girlfriend so time to ...do things ;)
I could not resist today had to try out of I can speed up the stuff again by sending clusters instead of sectors.
Seems with 8k sectors -> 16k clusteres it's not getting faster alot like it got with smaller sectors... A bit sad but anyway 600kb/s transferspeed is ok I expected alot less...

Seems alot of demos clearing the entire memory. That made quite some problems with the my hd driver (so far the demo loads during the demo runs) because I need some ram to store the old calls for the hdv routines.
But I'm now saving them just in the FPGA. This helped alot to get demos to run.
Currently all is working (what I've tested of course) except of Drone and Hires from Paradox. Drone is clear because the HD emulation is too slow. Hires dunno why anyway... (hm seems it only works from floppy)...
Ah Signals (with streaming music) from dhs works too... niceness... And besides this no crashes anymore

I tried out today to share a folder to the Atari from a folder which is shared from my Raspberry worked so far ... nice . But of course it's not possible to recognise changes in the folder since I'm using Windows functions to recognise and this seems not to be possible to use on unc volumes...anyway but still funny that this is working...

Speaking of Raspberry. I had today a look to my power supply of my Raspberry (using it for git and stuff) after running some weeks the sd card was always filled with crap.


Hmm great. This is a strong power supply done esp. for the Raspberry. So better to check them from time to time ;) Good that it didn't light my house...

22.05.2020 While I was watching the Outline live stream I optimised a bit the transfer routines like finding better values for the USB buffers, reducing the FPGA cycles for receiving and copying the sector buffer via movem.l to the destination I could squeeze out again some kb/s
Now I'm almost at 600kb/s (measured with HOWFAST).

This is nice Sea of Colours is working fine now. Unforunately Drone is still crashing at startup... Hm anyway.
I guess I could speed up again around 80kb/s if I would transfer clusters instead of sectors. But well I'll put that on the todo list maybe I'll do later...

So next is to make a release so beta testers can test a bit.

22.05.2020 Continued the hd folder share today... Now it's possible to change stuff in the shared folder like adding files or adding entire trees. This is pretty cool I always wanted to do this.

Well I've been using Ghostlink for a while years ago. This was quite a cool thing back then. Hm about 15 years time ago I had the idea hm why not doing this via USB this would speed up all alot?

But at this time I wasn't very into Atari ST system coding and hm I even didn't know how to add a volume to the desktop.
Mostly when I did stuff on Atari the first thing I killed was the system...

And well after reading the source of a ram disk from the 80's I saw how easy it is to a) add a volume and b) reading from a virtual volume. Good that Atari added some memory pointers to inject stuff.
And besides I wasn't able to do the hardware for this kind of stuff. Well at this time I used a 80c51 like 8 bit cpu which was let's say really bad... Anyway

Initially I planned to do changes to the of the fly created drive image by deleting files and adding the changes to the volume. But well I did a time measure now and hm building up the drive image for a 100mb needs about 0.01 seconds (with sdd).
Call me lazy but I just build up the volume each time I've got changes. It's fast enough.

Small demostration of the folder share:
19.05.2020 Implemented the scanning of sub folders today. Works quite good so far. Some demos do not work no idea why atm..
Even Sea of Colours works.... ok not fully ;) hangs after 3/4 of the demo anyway...
Some bit of debugging is surely needed... somehow some demos crashes with 4 bombs when they exit...hm

15.05.2020 Continued the folder share today... Now I can share the root of a directory without subfolders... was easier than expected... so next is to scan the subsolders...
This is fun coding... just small changes with cool effects on Atari side...
Volume image build up is even quite fast it's about a second for about 40 mb... But need to do more tests... niceness...
Booting up from the hd even a desktop.inf works didn't expected this ... ok you can't save it because of no write support currently but anyway ...;)
Hmm somehow there is a loose contact in my hxc floopy emu that sux a bit...

Btw... small song advice "tool - the pod"... I like that song... i used to hear that song in a club... but well corona you know ;)

13.05.2020 Today I could start my first file from the new folder share... this is pretty cool ;)
Ok currently it's not really a folder share more a I create a volume image on the fly and with the provided methods of the classes I add a file to the volume image.
Of course the first file was REALTIME.PRG ;) Since I have the ability to test with different sectorsizes I used HOW_FAST.PRG to see how the different sector sizes affects the speed.

The results:
1k 250kb/s
2k 320kb/s
4k 400kb/s
8k 520kb/s

But why different sector sizes affects the speed? That's because high sector sizes will result is less callbacks to the pc. USB uses some kind of send and receive raster means each callback needs some time before it is send or received.
I could increase the speed a little bit by always sending clusters to the Atari but anyway I think this is fast enough...
So next is now to start scanning the directory and add these files to the volume image...

11.05.2020 Puh that small thing I wanted to test before I can release the new price turned into a real problem.
The new FPGA board has slight different pinnings and I wanted that the firmware works on both revisions.
Unforunately I did not get this to run until now. So I have two different versions of the FPGA firmware but this only affects the beta testers.


So time for the final price. Check Final price.


Beside this I improved the make release script alot. It's now building almost everything that saves time and reduces errors... Also continued the hd folder share included now a file cache to speed up a little but fat implementation is not done yet.

06.05.2020 Oki back to the folder share. Currently I'm working on files in a directory means converting a pc directory data into a atari data and in the end hd directory sectors.



First small success... the on the fly volume image creation works so far and adding a file (without data) to the volume directory too. Next is to include a fat to hold the data.
But quite some stuff to do left but enough for today I'm still ko from my last jogging session hm ;)

06.05.2020 Really good steps in the last days...

The new FPGA updater is done now and needs about 19 seconds to update the FPGA including verify. This is nice I'm feeling alot better with the new updater now...
Well the old updater was based on a Xilinx source and hm it was really hard to understand whats going on there. So the new updater is fully done by me and it's just a source which is talking to the prom via SPI.

I was working a bit on the make release scripts well before I had to do quite a few things by hand esp. creating the programming files for the config rom were really a pain in the ass. Now they are auto generated niceness...

Beside I fixed really really much smaller bugs, continued to make the HD implementation more flexible well before it was quite a bit hardcoded.

Yesterday I continued to implement the folder share from PC. The folder share includes a on the fly build up of a drive image so it's quite flexible to test values for the created hd image.
So far I can create an empty volume on Atari so I tried a bit with the values esp. the sector size to see if a "Show info" on Atari shows how big the volume is.
The volume size changes that is good yesterday I could create a 150mb volume ... but ... this doesn't mean this really works.
Next step is to create the directory sectos out of the shared folder. Really exciting stuff ;)

I've got from tin/ggn a new version of bugaboo which works (can't test) on falcon but the nicest is it assembles with vasm. I did the first ultraDev version of bugaboo with Turboass on emulator hm a pain in the ass ;)

03.05.2020 Changed the FPGA updater now to write the spi prom directly. Works so far the FPGA boots up with the written config file but need to include some kind of verify or so.

Really nice is the update needs about 15 seconds now ok without verify currently but anyway will be alot faster than the old updater.

03.05.2020 Still testing the new FPGA board a bit. I recognised it does not boot if a ram chip is soldered on the cartridge. After some hardware debugging I found the problem luckily easy so solve (just a pullup resistor ... puh) and normal usage no problem since the ram is not soldered in by default.

So FPGA board is working now. This is quite cool didn't expext it works that good well I didn't do a prototype before normally I need to because I'm not the mega hardware guru ;)
Next step is now to change the FPGA update mechanism.

The old FPGA board had a Xilinx prom which is not so easy programm. You need to use a incircut programming source from Xilinx which is a bit stressy to use also you need to access the prom via a standard JTAG interface.
This is why the cartridge has a JTAG interface included.

When I designed the the new FPGA board I changed from the Xilinx prom to a standard spi. The spi flash can be accessed directly thru the FPGA which means I can skip the cartridge onboard JTAG interface and cable.

That's nice so the cartridge will get a little cheaper also the new FPGA board is cheaper. But let's see I want to include the new update mechanism before I'll tell the final price.

So... time to read the spi prom datasheet... stay tuned

17.04.2020 Earlier this week some more FPGA from China arrived:


so finally everything arrived which I ordered back in january. Yeah took really long but anyway everything arrived I'm impressed and happy;)

Today my new toy arrived:


Hm T962? What could this be? Let's unbox ;)


Still no idea? Well if you read the diary a bit I started to use stencils to print the soldering paste, place the components and in the end I do the soldering in one step via hot air by using a hot air soldering thing.
This saves unbelievable much of time. But doing it with hot air has some problems:
a) if you aren't careful your componets are blown away. I'm using 0402 components (1mmx0,5mm) and this can happen quite easy. And if it happens it a real pain in the ass.
b) Another problem is that you sometimes forget to solder or soldering is not 100% done.

So the T962 is an oven for soldering.

But before you can use the T962 you should really add some mods (like installing a custom firmware, cold junction mod, exchanging internal tapes and adding correct grounding, and changing the fan) otherwise it's unusable, unsave and surely even toxic fumes because of the tape...
But why buying such a device ? Because it's cheap and the changes aren't so heavy to do and after it it seems to be a pretty nice oven for home stuff.

So before I can use it I opened it:) How it should be ;)
Updating the firmware:


Luckily I had a USB to serial thing (red PCB) to use for the firmware update.
So next was to calibrate the temprature. That was quite a bit stressy. I didn't met it 100% but anyway it works so far.

First PCB I soldered in the oven:


Worked fine so far for the first run. Everything is soldered correctly. Nice nice that saves of course time to build up things...

02.04.2020 Seems I have a run currently... Thuesday the hd implementation started to work today I build up the new self made FPGA board.

And? It works fine that's pretty cool.

Looks like this:


Oh just seeing I should clean the PCB a bit ... anyway... On the left you can see my new board on the right the old Waveshare board.
Unforunately I forgot a 5V power trace on the PCB (the cable on the left side) but anyway seems that's the only mistake I did...

Main differences between these two boards are:
a) my has a better decoupling for the power lines
b) FPGA updates are easier since the FPGA is booted with a SPI prom
c) it's cheaper but more work for me to build up.

Have to build up another to see if I can savely produce the FPGA board and how long I need to build up.

31.03.2020 I could get the new feature to run today. It's a hd implementation.

Have a look to see it in action.


Sorry for moving the mouse with the keyboard ... currently I do not have a mouse for my atari...
Yes again realtime.prg and blubba.prg ;) I use these mainly to test a) they are big and b) they made most of problems during development.

All is in a beta state currently. The hd implementation is a hd image placed on pc.
ultraDev adds a volume C to the Atari desktop (plug and play) and you can use it as a hd.
Do not wonder about the cartridge volume it's added when you create a cartridge which is not started at reset directly.
Currently the hd image is not mega big around 18mb but it's possible to do about 512 mb didn't test yet. For this I need to do a tool to create a hd image anyway.

Was alot easier than expected. Browsing the directory worked quite fast but unforunately it always crashed when I started a PRG-file.
After reading alot and debugging I remembered I read that TOS only supports 512 bytes sectors. My image has 1024 byte sectors
Yep and that was the problem if you reallocate the sector caches it works fine... great ;)

To add stuff to the image you can use for example steem. Just mount it add stuff and start up the image with ultraDev.

How does it work?
You can start the ultraDev command line tool in a server mode means it does not end and serves all requests from the Atari.
It's in a early state with no write support I'll add soon. Also some demos do not work like drone or sea of colors (main reason of doing this because I wanted to see it on real hw ;) ) have to trace down why it crashes...

But I'm happy except of some demos it is working quite good. Not mega fast about hm I guess about 200-300 kb per second. But with a bigger sector size it will get faster...

30.03.2020 Yay... Vacation started today so enough time build up the first FPGA board... So I did today first stuff I've tested worked so far.
Uploading the bit file, booting from spi, USB communication and leds are working. That's nice!
Puh I'm happy that works so far ;) esp. because a) I did the PCB without doing a prototype and b) well I ordered FPGAs in china and I was expecting maybe fakes.

First time I soldered with the sencil hot air technique a 0,5 pitch ic (the FPGA) it worked but have to reduce the pads size a bit to print a little less soldering paste to the PCB. After soldering there were quite a few soldering joins between the pins.
Also placing a chip with 0,5 pitch on the PCB isn't easy somehow.
If you didn't place it correctly and you have to shift it a bit the print of the soldering smears over the pcb and it's harder to see if the IC is placed correctly. But still less work doing it like this then soldering all by hand.

Looks like this upper side:


Lower side:


Of course this is not the version for the cartridge this is the full build up for some experiments. I'll do a second one this week to see if it is working with the cartridge too.

28.03.2020 Some good news ;)

Finally the FPGA arrived today:


But took really long to get here about 9 weeks. I guess since the shut down in China because of the corona virus alot of snail haven't been send. Anyway it's here now that's cool...
This is really a perfect timing my vacation starts next week to enough time to build up the first fpga board. Keep the fingers crossed it's working ;)

20.03.2020 No update for a long time ;) Well have been a bit lazy to update the page. But quite a few things happened.

New FPGA Board
In January I started to design a FPGA board which is compatible to the waveshare board. Since the waveshare board is quite expensive and well dunno if they read the datasheet of the FPGA at waveshare but decoupling capacitors aren't really how Xilinx suggest them.

Looks like this:


As you can see the FPGA board is quite a bit bigger than the old one. This is because I wanted to create a FPGA board which has dac, switches, sd-ram, vga and usb on board for my future project but it should be also usable as a FPGA board for the cartridge.
So on the left the smaller ones are the same PCB but the left and right is cutted.

Small close up of the cutted board for the cartridge:


The PCB are again from china this time from JLC PCB but pretty good quality again.
But took quite a while to get the PCBs. When I ordered corona virus just started in china. So pretty understandable that they have other things to do. But they arrived. Thanks guys ;)

Unforunately I can't finish the FPGA board to test since the FPGA from china didn't arrived yet. If the board is working so far the cartrige will get a little cheaper. But let's see... If it doesn't work ... not ;)

Creating selfmake stencils
Soldering the PCB can be done the old way like iron and solder or a lot easier method using stencils. You just print the soldering paste on the PCB with a stencil and then you place the components to the PCB. In the end you heat up the entire PCB and all gets soldered.

Pretty cool technique and works really good. Well I want to use this technique for my self made PCB too but how do I get the stencils?

For this bought a cutting plotter:


This cuts in a transparent foil the pads so you can use it as a stencil. Pretty cool...
There is a tool esp. for creating these stencils with a cutting plotter but getting this to run was a real nightmare. The printer didn't start to print and ended up in debugging and chaning the python code. That took light years.

In the end I got it to run. Soldering for the lower side of the new FPGA board done with the self made stencil:

Tbh I'm a bit proud... the soldering looks almost perfect ;)

Beta testing
Tin was testing the cartridge on Mega ST including the reset cable. He said it's almost working perfect. On other systems aren't too much tests done yet. On Falcon it seems to work including the reset cable.
Tin and ggn are working on a more compatible Bugaboo which is working on Falcon too.

New release
After all these hardware things I started to work on the 0.51 release since a few days. Already fixed some bugs and it's now possible to send data max. 16kb via the command line tool from the pc to the Atari.
Also started working on a new feature. But let's see if this works out so far ;)

That's it so far ... stay healthy ;)

06.01.2020 Number 3 is alive... Ok almost at least soldered but not tested yet. Build up worked pretty well. Damn that hot air technique soldering is so cool anyway....I'll test tomorrow too tired today. Well work started today and had a longer Bloodborne session yesterday...;)

02.01.2020 Prepared the first release today it's downloadable in the files section. If you want to have a look to the docs and 68klib and stuff...
ggn's FPGA arrived some days ago. With some luck the ultraDev PCB should arrive today or tomorrow.


30.12.2019 Yesterday I tested a bit the fpga update. Installed the drivers on fresh laptop with no development stuff installed and did a fpga update. Seems to work. Puh ;)
Also did some scripts for doing a release which copies all stuff to a directory. Unforunately there are still quite a few steps which need to be done by hand anyway.
Today if nothing goes wrong I'll send the first PCB to ggn to beta test a bit. Let's see how this works out ;)
Oki that's it for 2019 and this project. I Hope you have a good start into 2020...

28.12.2019 Did a bit of tuning on the USB transfer routines today. I can transfer the realtime.prg demo which I used to demonstrate the cartridge speed (see pictures) in 0.8 seconds instead of 0,94 seconds. This is a speed up of about 15% so the transfer speed is now about 967kb/s. This is nice !

The 68k library is now done. Added some nice printf like hex value printing means you can print a string like "bla bla %b %w %l" and the print routine replaces it with the hex values which are passed via a-regs.
You can recognise the cartridge clean, getting the version numbers of both fpga and 68k rom now.
But I recognised the cartridge 68k code needs some cleanup ;) I'll do tomorrow.

So from the stuff I can do here I'm almost done now. Ok getting Bugaboo to work on every platform and getting the cartridge to run could be some work anyway.

Time for some Under Construction live stream ;)

27.12.2019 Yay user manual is done... 11 pages of bla bla.
I'm really happy this is done. Ok need to read again tomorrow but anyway. So enough for today. Tomorrow I'll do the last things on the 68klib and then I think I'm done to let the beta tests see if it works so far...


27.12.2019 X-Mas stress is over so time to continue ;)

Changed the font for the debug screen today. I found it hard to read with a bit of distance to the screen. Maybe my old eyes but anyway ;)...
Today I included a terminal which means you can print out text and the stuff scrolls up.
Looks like this:



This is also part of the examples. With the terminal you can create at the bottom a scroll area maybe useful if you want to display static stuff at the top. But you also can scroll the entire screen. During init you set the starting line of the terminal.
So the debug screen is done now I think. Also the 68kLib is nearly finished. Only have to code a cartridge detect, getting the version numbers of the 68k/fpga firmware. Also providing a save way how to get the pointer to the jump table.
The jump table is used later for example for loading stuff after the programm is started. I'm planning to include some kind of disk loading so you have a disk image on your pc and you can do some kind of trackloading from pc during development.
But this is a future feature and currently not included in the initial release.

Besides I started to write a user manual... Hm really exciting...

Ahh can you hear that too? My PS4 complains and wants to get played ;) Bloodborne hm I guess I need to do a break ;)

23.12.2019 Productive day today...
Continued the 68k service library routines for the cartridge I think most of the stuff is done now.
To ensure for a release all is working fine I started a few cartridge examples and to show how to use the 68k library.

One thing was nagging me. Some time ago I skipped the bitmap mode for the debug screen because there was not enough memory on the FPGA left.
I really would like to have a bitmap mode but doing it with the normal resolution in 40x32 the image would be really small.
Yesterday on the couch I had the idea well I'm using an FPGA so I could double each pixel to fill the screen a bit more... Well no problem!

Looks like this:



The bitmap mode can display an image of 128x128 pixels. Not impressive but anyway better than nothing... This is part of the examples how to display an image.

So the debug screen is pretty close to be finished now maybe here and there some additions to the video chip most of the ppl will not need but anyway ;)

23.12.2019 The timing issue is gone niceness...
So I continued the debug screen... Included some new features like the possibility to get the x/y raster beam position and setting the back ground color. Before only black was possible.
In combination of raster beam and back ground color it's now possible to do raster lines.
Ok no one needs but as I said earlier doing the debug screen is the most interesting part for me to code also a great learing example how to do things.
I'll include some more things I think. I always wanted to code a "video chip" that's so much fun to do.
Besides I started to code a 68k lib with service routines for the cartridge like handling the debug screen features and detecting the cartridge and stuff...
Unforunately half of the day I've got migraine yesterday :/
This is no fun ended in laying on the couch in the dark with hearing some music. Damn that's so unproductive anyway.
So let's see what the head says today. Currently looks good and hopefully I can do more than yesterday...

21.12.2019 Back from the vacation... Was nice really relaxing...
Had a look today to a timing issue I have since I included the vbl flag for the VGA screen. VGA clock runs in 54Mhz normal things run at 100Mhz means I cross clock domains. First time I used a signal which is generated in other clock domain. Seems the timing check always gives a timing error then. The solution is just to ignore these pathes it seems. I'll try tomorrow...

Btw. Tested ggn's ultraDev PCB now for some days. I think I can send it next week.


12.12.2019 Ah well ;) I could not resist recoded the debug screen output today and now with state machines (what a wonder) all is fine and working. I knew if I would take that undone thing into my vacation I would think the entire time about it. So this was to get the head free to relax ;)

But really cool what I have learned because of the project in the last weeks in FPGA things. It's always good to have a concrete problem to learn stuff. Sure maybe not that interesting for most of the ppl because they do things on emulators anyway.
I have been working quite a while with Tao a year ago on a vscode plugin for 68k coding including clock cycle counting or register usage of the selected block and parsing the source to have a more comfortable editing like jumping to the source when you click on a bsr label. It's almost finished after that project we will finish. This is how the idea was born to start stuff directly out of the vscode. The development plattform I ever dreamed of.

I just remember when I've got my first Seka version on Amiga in 87 how happy I was. Just changed from c64 to Amiga and wow I an edit a source ;).
Before I only coded in Smon a debugger on c64 no source if you forget an instruction damn ;)
But funny how the things changed for a long time Turboass have been my fav. development plattform I could not image a better thing... I met markus fritze once in a small computer shop in hamburg a nice guy showed me his turboass in a beta state and the speed holy shit... But took some time till I used turboass alot at this time archimedes was my plattform

But tbh vasm annoys me. The vscode plugin needs vasm currently but hm maybe I need to have a look to rmac and add the needed features to it...


11.12.2019 Tried to fix the debug screen problem today... Ah well ;) I did it without state machines. I knew that how I did isn't good and to fix the last bugs is too heavy logic.
But no heavy task I already planned to recode it... I think this is a typical c-coder problem if you are a beginner in FPGA things not to use state machine. Normally I don't do was a try and didn't work so always use state machines if you do stuff. I'll note it on a post it for future ;)

I think that's it before my vacation. Need to prepare some stuff for the vacation also my Ps4 wants to get played ;) anyway ... Going to Boltenhagen (Baltic Sea) in a few days for a week. This is how it looks like:



A small village to cool down from stress in the winter time there is really no one at this time. In the summer time it's filled with alot ppl visiting the beach.
So next week will be "full" of no computers, no internet, no tv, no telefone, no atari, no work, no pizza (damn) and stuff...

10.12.2019 Luckily today was alot better.

Number 2 lives:



On the left the PCB for ggn. But I'll not send it before x-mas I think. Want to test it a bit before I send ;) Also my vacation starts soon and I have to prepare some things before like pack things and hm maybe getting some x-mas presents ;)

Build up worked quite good. Learned alot with the "new" hot air technique and it's getting better.
One thing is a bit stressy currently. After soldering with the soldering paste the PCB is very sticky and hard to get off even with alcohol. It's like a small film of something on the PCB which even avoids the connectivity of the PCB connector to the Atari.
Have to google a bit how to remove this shit... But anyway number 2 is working that's fine...

10.12.2019 Ah well yesterday was these kind of days nothing really worked. I was searching phantom bugs and bla. For example I'm using a floppy emulator and if it's not connected it seems the cartridge is not started.. If you connect it works. So I was searching first I thought it was the new build up of the cartridge ...

Have to check the TOS sources again later if this is really the reason. I think if there is no floppy the TOS just do not call to the cartridge because I'm using the entry point directly before the floppy boots. Means no floppy no call or so.

And some other unproductive stuff. So I stopped working after a while was better not to destroy stuff ;)

Besides as you know the cartridge needs a cable from inside to preform the reset. So I checked the schematics of the Ataris and searched where the cable needs to be soldered.
But somehow this is stuipid dunno if ppl want to solder a cable to their Atari this means you need to open up and stuff apart from that dunno if ppl are able to solder... Also quite a bit of work for me to find the correct positions maybe there are different revisions of the boards?

Hm ... When I was in bed shortly before I fallen asleep I had the idea hm the Atari could get the information if if it needs to reform a reset. The information is already available since the Atari can check the state machine of the FPGA.
So how about a small inserter code to your vbl routine which checks the FPGA state machine and if it is in the Atari reset state it reforms a reset?

I think I'll include this of course this does not help if the Atari crashes and not as good as the reset cable but better than nothing. Also needed to include this into the bugaboo but anyway I set it to the todo list.

I really hope today is more productive than yesterday ;)

05.12.2019 Continued the debug screen today. Unforunately the FPGA internal memory is already 95% means currently hard to realise a bitmap mode for it. Tried alot like reorganising the ram also tried to reduce the upload buffers for the PRG file (which is 16kb) but this slows down the upload so this is out of question to do.
And reducing the cardridge rom (which is 16kb too) is no option. So I finally decided to skip the bitmap mode.
The other question how useful it would have been. Also I want to save some memory for later use.
So uploading a font with 256 chars is enough I think. This is possible and working now.

Below a small screen I coded today for the debug screen. It shows the usage of self defined chars.



The red lines are scrolling to upper left to test if a permanent upload of a char works too...
To have a clean scrolling I implement a vbl flag from the VGA monitor looks nicer ;) This is what I really love in FPGA coding. If you need something you just include it.

But can be also a total nightmare when timing constrains issues appear like before. Also debugging is hard to realise. Yes of course you can simulate to ensure your logic itself is working but that does not ensures it works in the end.
For example at the very beginning I had real problems to get the cartridge rom to run. Sometimes it worked sometimes not.
The problem was how I grabbed the A1-15 values. In simulation all worked fine but still it didn't work. After some time I used chip scope a tool for the FPGA to do something like a logic analyser for the FPGA pins.
And what I saw is? The A1-15 values are changing alot even during the 68k did not finish the instruction. How comes? Hm I'm using a STE (DMA) also the shifter uses the bus to read data and I didn't thought about that. So in the end it was clear why. I need to grab the values when the 68k accesses it. Silly bug anyway.

But the debug screen is not done yet. Fixed quite a few bugs today but it still has some. I just hiding them very good in the photo;) The first chars on the left side are wrong I'll trace down next week.
But hard to resist not to code more for it like a scroller or a rotzoomer but anyway want to finish that thing. It's like working on an old plattform like let's see what you can do with it.

But enough for today... Well bought quite a few new games for Ps4 on Black Friday and they arrived today so need to check them out ;)

Btw. next week I'll build up another cartridge from the sample PCB. This one is for ggn to do some more beta tests. I'm really curious if it works on other machines...

05.12.2019 Ah great timing issues are gone. I used the wrong clock for the font ram.
I'm using a simple dual port ram which enables to read and write at the "same" time with two ports. For both ports you need to specify which clock to use. Reading is the VGA clock which is running at 54Mhz to meet the correct frequencies for VGA display 1280*1024 (108 mhz it is but I only output every second pixel) the other is the write clock which is 100mhz. I used for both 54mhz which produced the problem.
Puh ...I already expected a endless search to solve the problem because timing constrains I really did get into yet. Only set one for the clock anyway... This is cool ;) Ok back to work just checked that out...

05.12.2019 Continued the debug screen yesterday and included setting the print position and added the possibility to upload a font. Works so far... Unfortunately I have timing constrain failed path in the font upload.
Timing constrain failed? Well when you do FPGA things your stuff needs to run at a specific clock means your logic must meet the timing constrains.
If something it is too slow you get these errors. When a flip flop switches to the next value with the data must be available shortly before the next clock rises.
Then the path to the flip flop is too long you get a setup timing contrain fail. This I have in the font upload which I do not understand currently since the logic isn't that heavy. It has the same logic level like writing a char on the screen.
Well I'm really no expert here and analysing is a bit strange since the text outputs of the timing contrains report I do not understand currently ;) Well I'm a beginner and luckily I never had that problems.
So I have to investigate a bit I guess the placement of the logic on the FPGA is not optimal. There is a FPGA editor where you can inspect this and maybe change it but didn't understand the tool yet ;)
So needs surely a bit to solve this. Ok I could reduce the speed of the design this solves the problem but this is no real solution.
I expected this will come esp. when the FPGA gets more filled anyway. A bit stressy now but that's live ;)

03.12.2019 Did not finish the debug screen today. Well I could not resist and build up the first PCB sample

> If you are interested you can check out the build up blog<

Some pictures of the end result



Lower side...



The most exciting moment is which? Yeah check out if it works ;)

And it worked without any change.... Coool. Even all features are working with the PCB revision means this is the final PCB layout. yay

And besides for the first time using this hot air technique it worked unbelievable good. I think I'll use this for my future projects. This saves so much time and less error-prone during soldering hm and in the end the soldering result looks almost perfect...

I'm really impressed.

So debug screen have to wait till thursday enough for today. Got some new PS4 games I have to check out ;)

03.12.2019 Unbelievable 2... The PCB arrived a few minutes ago. That was fast unforunately expensive too..





After a closer look. They are looking really nice. Good silkscreen, soldermask and tracks are looking clean...

And last but not least the stencil masks for the soldering paste.



Cool so you know what I'm doing later ;) I'm really curious how that works out with the stencil mask. I'll do a small blog of the build up.
But first some stuff at work has to be done... Mäh...

03.12.2019 Unbelievable... The PCB passed the custom duty at weekend and now they are in Neumünster which is only 35 km from my home. So let's see how fast I get a message that I can pick it up at the custom office.

02.12.2019 The blue is gone and what would you expect to write to the screen for the first time?



This of course ;)

The colors are a bit wrong because of camera. They remember more to spectrum colors but anyway enough for a debug screen. So the text debug screen is almost done now.

Writing to the debug screen works like this:
move $fb0000+(((%111<<8)+($41-$20))*2),d0 (hopefully I didn't do a mistake here ;) )

This will write a white A to the screen.
Looks a bit strange right and why reading? Well the cartridge port has no write signal. So you need to create your write by a read from a specific address.
Each read to $fb0xxx will write the value of xxx to the debug screen and the destination address in the FPGA is incremented by one each time.
When you read 12 bit of the address is used. 3 bits (rgb bits) for the color (%111<<8) and the asci value -$20 because the font does not have chars for the first 32 chars. *2 because there is no a0 signal on the cartridge port means no odd addresses are possible.

So what is missing now is to set the internal FPGA destination address where to print. But enough for today maybe I can finish the text output tomorrow.

Hmm unforunately I did a mistake in the calculation for the debug screen bit map mode memory. I guess the memory will be too low for a full bitmap map anyway. So I'll include a font upload from the Atari I think.


29.11.2019 The debug screen slowly starts to work.



Nice blue btw. anyway ;). So VGA output basically works so I need to code the Atari interface to write something more useful to the screen.
Hm it would be possible to upload a font from the Atari but not sure if this makes sense...Have to think about it...
Unfortunately no bigger steps today still not recovered 100% from the cold.

Besides I called round about 3 times DHL today for the PCB samples. That sux. Currently it's at the customs duty in Cologne. I hope it passes the customs duty next week.


26.11.2019 Today I've got an email from China. Included was this picture:



A bit bad quality but shows the PCB samples I ordered are done and on the way to Germany.
That's cool. I hope it's soon here because on 14.12.2019 I'm on vacation. But let's see how fast is DHL Express from China.

Second picture was this:



That are the stencil masks for the soldering paste. I'm really currious how that works out never did this till now. But looks really easy if you watch videos on youtube.

Beside this only smaller steps with the project having a cold.
Started to work on the debug screen and had some thoughts what is needed.
I think I'll do a 40*34 text output where every char can have it's own color (8 colors in all).
And a second graphics mode with 320*256 with bitplane graphics this one will be b/w only.

22.11.2019 Today was a damn productive day. Do you know this? These days when you start to implement something and everything works with the first try? This day I had today... great ;)

So what did I do in detail:
-Kicked out the resident bugaboo feature since it's not worth the speed. (See below I was talked about it earlier). So the source is a bit cleaner now and even better the FPGA could run more speed if I need.
-Included new Bugaboo handling and stuff.
-Included that you can execute Bugaboo commands from the commandline tool
-Removed the reset handler from Bugaboo. Makes no sence somehow.
-The FPGA updater tool has now more useful texts. Before it was nothing ;)
-Improved the reset feature a bit. Before I had a delay in the FPGA in which the FPGA waited till the Atari is done with the reset. That's really bad a) not optiomal performance b) the machines are running in a different speed so I had to choose the longest delay. Now it's done with handshaking.
-Included and tested when the cardridge is not able to reset the Atari (no cable from inside). When you have to press reset is now signalised that all leds are blinking on the cartridge.
-Loading address is now shown on the Atari.
-Added receive timeouts on FPGA. Normally this is not needed but the problem here was when something went wrong during USB communcation (crash of the commandline tool or you disconnect usb) you had to press a button on the cartridge to reset it.

All is working pretty nice currently. I have to say that resetting the Atari is a really cool feature. You just Code some steps press run and you can see if it works. Next time just run again and it starts.

So my current todo list got really small today for the stuff I can do/test here (only have a STE) means I have only one thing on my todo list left. I have some more ideas left to include. But the feature set I have now should be enough for the first version.
So the last feature is the most interesting feature to code I saved that for the end. Doing the debug screen. I love that doing VGA outputs with the FPGA that's fun.
Of course getting the cartridge to run on every Atari will be a bit of work. I think the cartridge itself could work fine the problem here is the Bugaboo. But I hope I can send the beta tester (ggn) a cartridge soon so we can test alot more.

Btw. I'm still searching better distributors for the components and how to reduce the price for the PCB.
I'm now able to order PCB in china or better I already did order a few samples. So let's see if the quality is good and if they are working. You never know ;)

But I think the price for the cartridge will drop for sure.

20.11.2019 The new prototype is build up and running. But this was quite a bit of work.
Well did a mistake during expose the upper and lower layer were shifted a bit. Unforunately you can see this only when you drill the first hole.
The holes for the vias are 0,5 mm if upper and lower layer do not fit 100% you hit maybe a track during drilling and that happned sometimes and produced very strange results.
That's always the question rebuild it or try to trace down the problem. This time I decided to trace down but in the end it would have been better to rebuild because I needed a few hours to find this and quite frustating if you invested 2-3 hours to build up and it do not work for a long time.

The prototype is no beauty but well it works. So I have my final layout ok VGA I didn't tested yet but I'm pretty sure that will work since this is no rocket science and I already did this in other projects.

That's nice so I can sleep well tonight ;)

18.11.2019 Did alot surfing and investigations how to produce the PCB and optimised how to build up the cartridge to reduce work. Quite a bit of work so no big steps today.


Also it's possible to preorder now. Have a look to the menu.

17.11.2019 Etched today (hopefully) the final version of the PCB which I'll build up next week. No big changes I used the right FPGA JTAG connector this time, reduced the colors for VGA to 8 and added a better connector for VGA.

16.11.2019 Just after I woke up today I had the idea for a small and easy way to speed up again. Included it and well... works. Now I need 43 seconds to update the FPGA. Including erase it is 57 before it 100 seconds. That's really enough now. That's a speed up by 53x compared to the initial 38 minutes. Niceness.
Somethimes it's good to get some sleep ;)

15.11.2019 Unforunately what I was writing before wasn't true the update didn't worked earlier that was a mistake the prom wasn't erased. But it does work now ;). Changed to the Xilinx source I was takling about. That source was alot better but still had problems to get it to run anyway. But holy shit this was a real pain in the ass to configure the prom.
Speed it quite ok now. Erase needs about 15 seconds and programming the prom about 85 seconds. I could speed up I think by x5 or so but anyway that's fast enough. So the updater needs some more useful texts and it's done... But before a quick git check in before something is lost.
Nice ! So I can do things I'm really motivated to.

15.11.2019 The FPGA update seems to work now. It has the entire time somehow but I didn't recognised. Normally if you press the config button on the FPGA board the FPGA should boot but it didn't if I switch off and on it boots fine. That's a bit strange anyway.
But even if that works (more or less) I'll test something else I found a xapp from Xilinx about updating the FPGA prom from a embedded microcontroller. That source is alot smaller than that commandline tool I use now 68 sources agains 2. This is alot better to handle for speed up and stuff.

But puh anyway that was really stressy to include hopefully the other source is easier to include. It should since from FPGA side I do not need to code something because that part is done...
But anyway a step into the right direction will help for future projects for sure. This have been always a problem.

Besides I'm working on a new PCB revision hopefully the final one. I reduced the VGA output a bit before it was able to do 128 colors a bit overpowered now it has 8 that should be enough. Less to solder ;)

14.11.2019 The FPGA prom update is now alot faster 4 minutes almost 10x faster. Unforunately the FPGA does not boot correclty when reading from the prom. Hm that's bad. TBH a bit annoying problem to wait every time 4 minutes to see if it worked or not avoids you to do things you really want to do...

13.11.2019 Tried the bit bang mode today and did change something. Still slow like hell. But it's quite logical since the frame rate of usb is 1 ms. Doing a clock needs then 2 ms. So the JTAG interface needs a bit more then just redirecting the bits to the JTAG connector.
I already have an idea let's see if that works...

12.11.2019 It's alive ;) The new prototype is working so far I did some pictures during build up.

> Build up blog part 2 (soldering the PCB). (click)<

Looks like this:



Unforunately I did a mistake bla... I used the wrong connector for the FPGA (cable on the left side) the needed connector is 10 pins I used the 14 pin version.
Hm that's stupid so it's not the final revision... anyway still works but I need to use a adaptor to programm the FPGA. That I have to fix for the final version.

So next step is to see if I can a) compile the commandline tool to programm the FPGA b) I need to code a interface for the commandline tool and the FPGA needs to redirect.

(Few hours later)...The commandline tool for FPGA programming compiles on Windows now (Unix before).Added my device and changed the FPGA code to redirect. Well basic are working like jtag scan. Programming the prom is by far too slow needs about 38 minutes (never let it run to the end so I don't know if it works or not) anyway. That sucks. Maybe I need to use the bitbang mode of the ftdi chip.



07.11.2019 The layout for the new revision c of the PCB is done .



> Build up blog part 1 (doing the PCB). (click)<


07.11.2019 I did some speed tests today with the loading of Bugaboo to see how much the memory speeds up the Bugaboo loading.
Loading Bugaboo from memory on the board: 0,09s
Normal loading: 0,3s
The given time is only the transfer to the 68k memory. Not starting it itself.
Hm on one hand wow loading via USB takes only 0,3s on the other hand loading from the board memory is only 0,21s faster.
Well when I designed the board I thought it's maybe a good idea to have Bugaboo resident in the memory. I didn't expect the transfer is that fast. At the very beginning the USB transfer wasn't that fast but after tuning it it got faster and faster
So the main question is now. Is it really worth? To gain 0,21s? I don't think so. Furthermore it's the most expensive part on the cartridge PCB. So I'll skip the memory support for Bugaboo... A bit sad for the work but anyway makes the cartridge cheaper.
But I'll not fully remove it from the PCB. Maybe there is a usage for later projects? How knows...


06.11.2019 Currently I'm working on a new PCB revision which includes the last minutes changes from the prototype.

One thing is really stupid. The 68k code can be updated easily by uploading the image via USB. But how about the FPGA bit-file? You only can do if you have a FPGA programmer. That sucks!

So I tried to find a solution for this. Then I had the idea. The config prom (which loads the FPGA with the bit-file) can be accessed via JTAG interface. So I only need to have a JTAG out on the board to plug directly to the FPGA JTAG.
Luckily there is xc3sprog. A tool which is able to programm FPGA proms via command line and even better the source is included. So I only need to redirect the JTAG pins on FPGA and change xc3sprog a bit. Thats pretty nice. Let's see if this works.
The new JTAG interface is already included in the new PCB revision. Next step is to check the PCB for possible errors and then I'll build up a new PCB.