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.