New project - Pico based SIO device...

[woj]

...with particular support for normal and turbo CAS files (hopefully also mixed types in one file). Teaser in this video already posted in the TURGEN topic:

 

 

Since then I also implemented and tested normal SIO CAS support (managed to load the complete 60k Popeye CAS today). Generally, the goals of this are similar to those of the A8 Pico Cart, only on the SIO side. I will keep adding details as I go, I am currently too deep in the implementation work to actually document things 😜. Apart from ATX support, I have most of the things worked out in my head by now.

 

Some interesting findings about Pico in this respect:

 

1. It has to be overclocked to 250Mhz for the timer interrupt to be precise enough for Turbo 2000 PWM, even though we are talking about rather long intervals (250us).

 

2. It won't do 600 baud UARTing, at least not at 250Mhz, so I had to take the same approach of manual signal control through a timer interrupt as for the Turbo mode. No biggie since most of the code was already in place.

 

TBC...

[ascrnet]

What a great project I am waiting for the detail to build one. 😁

 

I am interested in helping support many .cas with various baud settings like 600, 700, 800, 1000, 2000, 4000 and 6000 I don't know if it will give the peak.😅

[phaeron]

Are you using the CPU to bit-bang the SIO output? If so, try using PIO backed by DMA -- it should be a lot more stable timing-wise.

 

[dely]

Awesome project!

[woj]

11 hours ago, phaeron said:

Are you using the CPU to bit-bang the SIO output? If so, try using PIO backed by DMA -- it should be a lot more stable timing-wise.

 

Sort of I am, one core is doing the GUI and file selection stuff, the other core is taking care of communications, and the turbo / slow SIO signals are bit-banged through a repeating timer interrupt and a small "next delay + bit value" queue. I did not know PIO was there for me to do essentially the same thing, so thanks! It looks like exactly what I need, just that reading about it so far is only confusing, and also looking at some RaspPI forum threads it seems I am not the only one confused  But I will get there.

[+poobah]

The beauty of the RP2040 is the PIO state machines.

 

[E474]

I was working through some online lectures last year (when I had a bit more free time), and you might check them out (particularly lecture 16, which is using PIO to implement a UART). See:

 

 

[woj]

After tripping over a couple of details I got the PIO to work, on its own it really isn't complicated and indeed very powerful, its queue system essentially replaces what I did by hand with a repeating timer, super sweet! So far I did not need to employ DMA for this, the effective buffer for 8 bits is sufficient so far, but at least I know the route to go. Yet to check though if it now all works back at 125MHz (on it this very second).

[phaeron]

7 hours ago, woj said:

Sort of I am, one core is doing the GUI and file selection stuff, the other core is taking care of communications, and the turbo / slow SIO signals are bit-banged through a repeating timer interrupt and a small "next delay + bit value" queue. I did not know PIO was there for me to do essentially the same thing, so thanks! It looks like exactly what I need, just that reading about it so far is only confusing, and also looking at some RaspPI forum threads it seems I am not the only one confused  But I will get there.

If you've been reading through the library docs, check out the RP2040 Datasheet. It has a much better overview of the hardware.

 

The PIOs are essentially programmable shift registers. For SIO protocol transfers, you could have the PIO program interpret the DMA data as a programmable delay followed by a data byte unpacked to start + data + stop bits. For tape transfers, it could be either just raw bits at the baud rate, or on/off pulse widths. Might also be able to handle almost all of SIO command frame processing, with the checksum being the main thing the CPU would need to do.

 

The DMA section is also worth looking over, particularly the sections on chaining and aliases/triggers. The DMA channels specifically have register aliases that are designed to make it easier to retrigger a DMA channel with minimal writes. You can use one DMA channel to queue blocks on another DMA channel, and you can even set up DMA channels to loop for an ANTIC display list like configuration.

 

One thing I just noticed is that the DMA channels can compute checksums, and particularly has a mode that would be suitable for SIO (sum). It'd be of limited use since the CPU would still need to do the final carry wraparound, though, so the PIOs couldn't use it directly. An optimized routine can also rip through the SIO checksum 32 bits at a time.

 

[woj]

Yes, I can now more or less see what PIO is capable of, as usual there are some fiddly details, like the FSK blocks in CAS files. For this reason, so far, for the regular serial tape support I am sending each bit separately as one PIO message, with the timing information. Performance wise this is sub-optimal (the PIO FIFO can hold 8 out of 10 serial bits for each byte), but it does work and scales to everything that can come from the CAS file. To do it optimally I should indeed send all 10 bits incl. start/stop bits in one PIO message, but then I would have (I calculated this on paper) a problem with precision handling of FSK data that comes in 0.1 ms intervals with the same PIO setup.

 

Speaking of which, face palm of today, after many successful tests I decided to try a CAS copy of the original Lasermania remembering it has some protections and FSK blocks. This did not work, for a couple of hours I was going through my code to figure out what I am still doing wrong. Nothing, it turns out, this particular CAS does not load, not on my Atari. not with Atari800 emulator, probably not with Altirra, it doesn't have the FSK block, I took the wrong file out of my drive. The one that loads (and does so with my Pico too, albeit something was wrong with the game after loading, probably one of the Avalon's protections in connection with me using PokeyMax, I have seen this behavior before with Avalon games, but maybe there is something that should have appeared on the SIO line that I did not take care of) does have the FSK block, which was also good to test the FSK block handling.

 

For the actual disk SIO I am honestly hoping that the UART will work with higher baud rates, for the tape so far the pure PIO with no DMA does the trick nicely, and since it is always going to be one way, perhaps I can avoid fully implementing serial in/out over PIO+DMA.

 

Oh, and now with the PIO in place the stock system clock of 125MHz does just fine with the Pico, no timing issues.

 

EDIT: The Lasermania CAS that does load when loaded in Altirra has a similar glitch after loading, so it is not something I did wrong.

Edited July 4 by woj

[ascrnet]

Hi @woj

 

When you have some time I leave you a collection of .cas with loaders made in my country. (they are all the same set) this would be to test how the compatibility works. 😉

Cas Chile.7z

Thinking a little bit in the future it could be made to record .cas files.😄

 

Regards

[+yetanothertroll]

1 hour ago, ascrnet said:

Hi @woj

 

When you have some time I leave you a collection of .cas with loaders made in my country. (they are all the same set) this would be to test how the compatibility works. 😉

Cas Chile.7z 40.78 kB · 1 download

Thinking a little bit in the future it could be made to record .cas files.😄

 

Regards

 

 

How do I create .cas files that Atari BASIC can read? It's the CIO's data block format that's getting me. I'm trying to stuff 24 years of Nor Cal hourly temperature data into a cassette file in Atari Statistics I format, mimicking Atari Statistics I's own CALTEMPS example dataset, to be read by my own BASIC programs designed for a stock 400 and 410, probably in Altirra's Warp mode 😂

 

Edited July 5 by yetanothertroll
Always one more bug or one more typo

[woj]

2 hours ago, ascrnet said:

When you have some time I leave you a collection of .cas with loaders made in my country. (they are all the same set) this would be to test how the compatibility works. 😉

Cas Chile.7z 40.78 kB · 1 download

Thinking a little bit in the future it could be made to record .cas files.😄

 

Mighty cool! Good statistics: 16 worked fine (one on the second attempt, all of the others on the first, I wonder if the OS CAS VBI bug applies here?), 4 did not (yet) - Cain II, Stac 1 & 2, Stac XE2. What is interesting is that the fastest of them all, Nhp Injecktor 6.0, loaded fine. On this occasion I also discovered that the FATFS implementation on the Pico (I used the same one as A8PicoCart) does not like dots in the file names apart from the extension. The ones that do not work - I will check them out, but it seems it is a timing issue, I did play with the timing parameters a bit, but no luck so far, I need to dissect the CAS files and see the differentiating points. I hope this is not related to the fact that I run my computer with PokeyMax4. 

 

Recording - well, I was already thinking about it, it is, however, rather difficult on so many levels that I currently do not see a good solution, not even a bad one in fact, so this will have to be dropped to the bottom of the priority list. (I mean - recording 600 baud standard records should be no biggie, but discovering fsk blocks, or discovering changing baud rates seems rather undoable).

 

EDIT: Huh, out of these 4 so far non-working ones, only one loads in Altirra (Cain II), the other 3 fail more or less the same way as they do on my actual Atari. So the question is - where do they load and are these actually loadable CAS files? Tagging @phaeron if this is perhaps of interest to him too.

 

Edited July 5 by woj

[ascrnet]

4 hours ago, yetanothertroll said:

How do I create .cas files that Atari BASIC can read? It's the CIO's data block format that's getting me. I'm trying to stuff 24 years of Nor Cal hourly temperature data into a cassette file in Atari Statistics I format, mimicking Atari Statistics I's own CALTEMPS example dataset, to be read by my own BASIC programs designed for a stock 400 and 410, probably in Altirra's Warp mode 😂

to do it from atari basic you must read the following book chapter 8. in altirra select a new cassette, activate the control panel and press the REC button.

 

3 hours ago, woj said:

Mighty cool! Good statistics: 16 worked fine (one on the second attempt, all of the others on the first, I wonder if the OS CAS VBI bug applies here?), 4 did not (yet) - Cain II, Stac 1 & 2, Stac XE2. What is interesting is that the fastest of them all, Nhp Injecktor 6.0, loaded fine. On this occasion I also discovered that the FATFS implementation on the Pico (I used the same one as A8PicoCart) does not like dots in the file names apart from the extension. The ones that do not work - I will check them out, but it seems it is a timing issue, I did play with the timing parameters a bit, but no luck so far, I need to dissect the CAS files and see the differentiating points. I hope this is not related to the fact that I run my computer with PokeyMax4.

 

wow 😱 Wonderful.... has better support than AVG Cart, Fujinet and Sdrive-Max I tested them all and not all of them work.

 

3 hours ago, woj said:

Recording - well, I was already thinking about it, it is, however, rather difficult on so many levels that I currently do not see a good solution, not even a bad one in fact, so this will have to be dropped to the bottom of the priority list. (I mean - recording 600 baud standard records should be no biggie, but discovering fsk blocks, or discovering changing baud rates seems rather undoable).

 

I am satisfied with the 600 baud standard, since there are several programs that use it. 😁 

 

3 hours ago, woj said:

EDIT: Huh, out of these 4 so far non-working ones, only one loads in Altirra (Cain II), the other 3 fail more or less the same way as they do on my actual Atari. So the question is - where do they load and are these actually loadable CAS files? Tagging @phaeron if this is perhaps of interest to him too.

 

They all load in altirra 4.21 but without acceleration. 😉  all of them work on atari, only the Injecktor has additional hardware.

 

Enclosed is another charger that I met in 2000 made in polish 😁

Cas Iron.7z

 

[+yetanothertroll]

52 minutes ago, ascrnet said:

 

to do it from atari basic you must read the following book chapter 8. in altirra select a new cassette, activate the control panel and press the REC button.

 

...

I'm trying to do it from an external Windows or Linux program that creates a .cas file, which I would then load in Altirra and have an Atari BASIC or FastBasic program chew on. Is there a reference for how .cas data blocks are formatted? I can extract text from .cas files but not build a working .cas from scratch. Thanks!

 

EDIT: To clarify, I did find https://a8cas.sourceforge.net/format-cas.html, but I haven't found much about how exactly SIO formats the block's data inside the data - standard SIO record chunks

Edited July 6 by yetanothertroll
What's in the block's data field?

[ascrnet]

29 minutes ago, yetanothertroll said:

I'm trying to do it from an external Windows or Linux program that creates a .cas file, which I would then load in Altirra and have an Atari BASIC or FastBasic program chew on. Is there a reference for how .cas data blocks are formatted? I can extract text from .cas files but not build a working .cas from scratch. Thanks!

I see what you mean, the Atari by default uses a 600 baud format which is the standard and each block is 128 bytes. read this book 🧐

 

34 minutes ago, yetanothertroll said:

EDIT: To clarify, I did find https://a8cas.sourceforge.net/format-cas.html, but I haven't found much about how exactly SIO formats the block's data inside the data - standard SIO record chunks

As explained in the .cas format for the standard, 3 headers are used: fuji, baud and data.

 

The other headers do not take them into account since they are for systems more complex than the standard one. 😉

[+yetanothertroll]

1 hour ago, ascrnet said:

I see what you mean, the Atari by default uses a 600 baud format which is the standard and each block is 128 bytes. read this book 🧐

 

As explained in the .cas format for the standard, 3 headers are used: fuji, baud and data.

 

The other headers do not take them into account since they are for systems more complex than the standard one. 😉

 

Hmm,

 

 

Aww yeah, that's the stuff 🤖💾

 

Thanks!

 

EDIT: Hmm, a mere 11000 randomly generated Gaussian-ish data points between -1 and 1 (-1,...,0,...,1)  fills both sides of a simulated C-90 tape. No wonder all these "turbo" tape schemes popped up!

 

Edited July 6 by yetanothertroll
Stock 410 tapes don't hold much do they

[woj]

6 hours ago, ascrnet said:

They all load in altirra 4.21 but without acceleration. 😉  all of them work on atari, only the Injecktor has additional hardware.

PAL or NTSC?

 

EDIT: No need to answer this, I quickly Googled what TV system you guys have back in Chile, took out my NTSC machine out of the drawer and the remaining 4 files worked fine (one on the second attempt - VBI thing again?). And I randomly tested a couple of files that worked on the PAL machine yesterday, they are all fine. 

 

But don't get too excited, over the night I also figured out how to do the PIO thing for the cassette serial properly, I will need to totally overhaul it and probably get back to the state of nothing works.

Edited July 6 by woj

[Overange]

What would be a really cool thing is to try and integrate it inside the original tape drives like the 1010.

 

Someone in the Amstrad community has done this with the cpc646 tape drive, and utilised the lid as the control panel.

 

 

 

[woj]

5 hours ago, woj said:

But don't get too excited, over the night I also figured out how to do the PIO thing for the cassette serial properly, I will need to totally overhaul it and probably get back to the state of nothing works.

 

I will probably scratch that, the new solution is not so brilliant after all and with the current one I got everything to work, perhaps what I can do is to add DMA on top to facilitate some buffering.

 

But I need some help in digging out some files. What I wanted to try is a mixed CAS with the regular baud 600 turbo loader and the remaining blocks being in PWM format to test the all in one go load. But I can't find a standalone KSO Turbo loader (preferably in the bootable CAS format already), only ones for the SIO version of it (called 2000F or 2001 by some). This particular set up is somewhat crucial to test CAS communication over two different input channels / pins at the same time (SIO plus the joystick port, the motor control is also separate). I remember from the old times the L1 / L2 / L3 names, but can't find anything out there.

[ascrnet]

13 hours ago, yetanothertroll said:

Aww yeah, that's the stuff 🤖💾

 

Thanks!

 

EDIT: Hmm, a mere 11000 randomly generated Gaussian-ish data points between -1 and 1 (-1,...,0,...,1)  fills both sides of a simulated C-90 tape. No wonder all these "turbo" tape schemes popped up!

 

Perfect, so as not to divert this thread too much. If you have more doubts you should generate your own thread for your case. 😉

 

10 hours ago, woj said:

But don't get too excited, over the night I also figured out how to do the PIO thing for the cassette serial properly, I will need to totally overhaul it and probably get back to the state of nothing works.

I am not in a hurry the more systems I support the better 😎

 

4 hours ago, woj said:

But I need some help in digging out some files. What I wanted to try is a mixed CAS with the regular baud 600 turbo loader and the remaining blocks being in PWM format to test the all in one go load. But I can't find a standalone KSO Turbo loader (preferably in the bootable CAS format already), only ones for the SIO version of it (called 2000F or 2001 by some). This particular set up is somewhat crucial to test CAS communication over two different input channels / pins at the same time (SIO plus the joystick port, the motor control is also separate). I remember from the old times the L1 / L2 / L3 names, but can't find anything out there.

I am also interested in these cases since I never knew them at the time. Some time ago a user @w1k was sharing a manual of a t2000 with the connection to the second player. I remember I added support in a8picocart for some t2000 cartridges that has a rd5 track off button.

 

I will look if I find one of those t2000 that has loader included in the same .cas.

[+yetanothertroll]

2 hours ago, ascrnet said:

Perfect, so as not to divert this thread too much. If you have more doubts you should generate your own thread for your case. 😉

 

...

 

On the other hand, I may become interested in building "turbo" .cas files from my statistics datasets sometime in the future, but a quick look at the rest of the a8cas docs, and, well, yikes!😱

 

[woj]

3 hours ago, ascrnet said:

I am not in a hurry the more systems I support the better 😎

 

So I overhauled it to use DMA on top of PIO to provide some buffering, but left the basic PIO method as it was. This was not strictly necessary, but I learned a great deal about DMA on the Pico, tripped over one thing for a couple of hours, now I am wiser, and I got the thing back to a fully working state. The good news is - all of your CAS files worked on the NTSC machine, as far as loading is concerned, the only exception is that one of them did not run well after loading, however, Altirra exhibited the exact same behaviour, so it should be fine (I think yesterday it worked fine when tested on PAL). This is fantastic, even if I do say so myself!

 

3 hours ago, ascrnet said:

I will look if I find one of those t2000 that has loader included in the same .cas.

I do not need a ready made complete file, but I could not find a 3 block CAS (or heck, ATR, have seen those too) loader that would load the KSO T2000 versions. (Tomorrow I should be able to get to the stage of being able to test a combined CAS file in T2001 mode purely over SIO lines, but for completeness I'd really need a working KSO bootable loader).

 

This is actually looking good, the next thing on the list is basic ATR support for D1-4:, once that is done it is mostly testing and polishing things and adding small functionality extras (like creating new ATR files or blinking widgets on the screen to indicate device's activity state). 

[ascrnet]

1 hour ago, yetanothertroll said:

On the other hand, I may become interested in building "turbo" .cas files from my statistics datasets sometime in the future, but a quick look at the rest of the a8cas docs, and, well, yikes!😱

 

Personally I would start with the basics before turbo systems as it requires more knowledge and the change in the Atari OS to increase the standard speed. 😉

 

21 minutes ago, woj said:

I do not need a ready made complete file, but I could not find a 3 block CAS (or heck, ATR, have seen those too) loader that would load the KSO T2000 versions. (Tomorrow I should be able to get to the stage of being able to test a combined CAS file in T2001 mode purely over SIO lines, but for completeness I'd really need a working KSO bootable loader).

 

Here I found several read the following thread from the friends of atarionline

 

23 minutes ago, woj said:

This is actually looking good, the next thing on the list is basic ATR support for D1-4:, once that is done it is mostly testing and polishing things and adding small functionality extras (like creating new ATR files or blinking widgets on the screen to indicate device's activity state). 

It's not bad, but will you support ED density well? Many modern devices don't support it very well. 😅

[woj]

25 minutes ago, ascrnet said:

Here I found several read the following thread from the friends of atarionline

Still not exactly what I am after, but perhaps booting the whole KSO system from a CAS with a PWM blocks attached would do the trick for the test.

EDIT: My hunch to do this test was good, the combined CAS file as such works, but there is a problem with correct detection of the motor line state during the transition from normal blocks to turbo ones.

 

25 minutes ago, ascrnet said:

It's not bad, but will you support ED density well? Many modern devices don't support it very well. 😅

 

If someone can explain what the particular problem is I can try to do my best to have it working well. Regardless of the impressions one may have of me, I am not that proficient with the Atari hardware and OS, for example, I never owned (and still do not) an actual disk drive for my Atari. 

Edited July 6 by woj