A8PicoCart - UnoCart on a Raspberry Pi Pico

[Mq.]

20 hours ago, ascrnet said:

This did not work, I have to use a timer "to study the C++ manual for RP2040". 😉

 

I also confirmed with the creator about this emulation and it is feasible to do it. there are two ways the timer one or to know the last address accessed.

I was thinking about a universal solution when I was started this thread about turbo systems cartridges. Checking the last address wouldn't be universal, because this address might be any different for a different cartridges images. Universal solution would be a timer between 2 and 5 seconds, or the button on unused pin for manual doing pull down RD4 and RD5 on demand.

But mainly you should decide if you want doing anything with this in the official firmware for A8PicoCart. As I told before, it's just my idea, I don't know if anyone want it as I want. If not, then it is no problem for me, I just will mount the switch in my particular one A8PicoCart.

Additionally the problem is, there is no such cartridge image type in emulators, which would save the info "this cartridge want the timer". So how we could sign such image for A8PicoCart that the firmware will know he should use the timer?

Edited December 1, 2023 by Mq.

[electrotrains]

21 hours ago, ascrnet said:

This did not work, I have to use a timer "to study the C++ manual for RP2040". 😉

 

I also confirmed with the creator about this emulation and it is feasible to do it. there are two ways the timer one or to know the last address accessed.

You can't use sleep_us() because the loop has to be actively responding to requests from the cartridge port.

 

Have a look at the functions in the time.h API provided, something like this (untested)...

 

// get the time 2 secs from now
absolute_time_t stopTime = delayed_by_ms(get_absolute_time(), 2000);
RD5_HIGH
..
while (get_absolute_time() < stopTime) {
  // Emulate cart
  ..
}
RD5_LOW

 

I don't think I'll be adding this to the "official" firmware - it's just a bit too niche usage, and there isn't an existing defined CAR type that does this. But obviously, feel free to create your own version with this behaviour.

 

Robin

Edited December 1, 2023 by electrotrains

[Mq.]

Ok, thank you Robin. I understand.

By the way thank you for this project and for share it.

[ascrnet]

1 hour ago, electrotrains said:

// get the time 2 secs from now
absolute_time_t stopTime = delayed_by_ms(get_absolute_time(), 2000);
RD5_HIGH
..
while (get_absolute_time() < stopTime) {
  // Emulate cart
  ..
}
RD5_LOW

 

 

thank you very much, I will check it out and see how it goes. 😉 I still have a lot to learn in Raspberry pico programming. 😅

 

1 hour ago, electrotrains said:

I don't think I'll be adding this to the "official" firmware - it's just a bit too niche usage, and there isn't an existing defined CAR type that does this. But obviously, feel free to create your own version with this behaviour.

absolutely right, but that does not detract from adding it as a new type to avoid modifying the 8k standard.

#define CART_TYPE_8K_TIMER			253

and so I accept the change or do you have a better idea?

 

I like this project because we can emulate all those cartridges that nobody is interested in or rare. 🤩

[Mq.]

6 minutes ago, ascrnet said:

absolutely right, but that does not detract from adding it as a new type to avoid modifying the 8k standard.

#define CART_TYPE_8K_TIMER			253

and so I accept the change or do you have a better idea?

Good idea. I think it should be implemented in emulators (Altirra, Atari800) first. I don't know how to do it, and I don't know who can do it...

[manterola]

21 hours ago, mytek said:

Ok I found the ATASCII equivalents for the SHIFTED Function keys, which might be more useful.

 

HOME CURSOR FUNCTION – TK-II assignment: PS/2 PAGE-UP
SHIFT- Fl causes the cursor to move to the home position of the screen as well as
producing the default ATASCII code 1C (decimal 28).

 

CURSOR TO LOWER LEFT CORNER – TK-II assignment: PS/2 PAGE-DOWN
SHIFT- F2 causes the cursor to move to the lower left comer of the screen as well
as producing the default ATASCII code 1D (decimal 29).

 

CURSOR TO BEGINNING OF PHYSICAL LINE – TK-II assignment: PS/2 HOME
SHIFT- F3 causes the cursor to move to the far left of the physical line on which it is
located (note. not the logical line which. in the screen editor. could be as many
as 3 physical lines). This function is performed by the screen editor as well as
generating the default ATASCII code 1E (decimal 30).

 

CURSOR TO FAR RIGHT WITHIN PHYSICAL LINE – TK-II assignment: PS/2 END
SHIFT- F4 causes the cursor to move to the far right side of the physical line on
which it is located This function is performed by the screen editor as well as
generating the default ATASCII code 1F (decimal 31).

 

If you run the following Basic program you can see it step through the four possibilities.

10 OPEN #1,8,0,"E:"
20 FOR X=0 TO 3
30 PUT #1,28+X
40 FOR DELAY=0 TO 2000:NEXT DELAY
50 NEXT X

 

EDIT: I should mention that these TK-II assignments work logically in the U1MB menus, as well as the Last Word, so there is precedence. And of course I added support to the SDrive Control Program for similar navigational outcome.

$1C and $1D are just Ctrl+- and Ctrl+= (the arrows keys).

I read mapping the Atari, and other sources plus the little basic program in basic to check CH in Altirra emulating 1200XL with F1-F4 keys, and I think I understand what is going on.

 

The first table attached shows the CH content for the Fn 1200XL keys. For example, F2 is $04 and with Shift key is $44. Then looking the table in $FB51 (default table for atascii conversion in XL/XE models which is pointed by vector KEYDEF $79,$7A), you can see that code $8B is returned no matter if Shift is pressed. I also highlighted the Atascii code returned for F1, F3 and F4. 

But then those keys can be redefined and the default definition are taken from a table located in $FC11 (pointed by vector FKDEF $60, $61) which, for example, makes that F2 key $8B behave like $1D (no addic. keys) which is CursorDown, or alternatively to $8F (with Shift key pressed).

 

So..... The A8PicoMenu program has its own copy of the XL/XE conversion table and should convert F2 key code $04 to $8B, but I guess it does NOT perform the final conversion of F2 key to $1D (Cursor Dn) or $8F.

Therefore, one solution should be to just modify the copy of the conversion table in the program for example to convert key code $44 (shift F2) directly to $8F. Another solution would be to use the ROM tables and implement something similar to what is done in the OS, which is check for the these special keys and then convert using the table pointed by the vector in $60 and $61  (LDA  ($60), Y).

I would like to hear your thoughts.

 

Edited December 1, 2023 by manterola

[+mytek]

7 hours ago, manterola said:

$1C and $1D are just Ctrl+- and Ctrl+= (the arrows keys).

No actually they are completely independent keys from the arrows, even though both will move the cursor directionality and in single steps (BTW, the info I posted about the ATASCII equivalents for the Shifted F1-F4 keys yesterday must have been incorrect).

Here's an updated version of the definition table you posted tagged with the TK-II recognized functions of the Normal and Shifted F1-F4 keys...

 

 

I use the F1-F4 arrow equivalents (not shifted) to double step the cursor across the screen for faster movement by combining them with the original CTRL+Arrow keys. This mode is toggled by pressing ALT+Q, 'Q' as in Quick. Since they are all distinctly interpreted as unique key codes, alternating between the two gets rid of the normal key repeat delay when holding down a key, thus the cursor flies around the screen at a much higher speed (double the normal key repeat rate).

 

EDIT: For normal arrow related menu functions I stuck with the CTRL+Arrow keys, which the current A8Pico Cart firmware currently uses (well at least the UP and DOWN arrows that is). The F1-F4 equivalents to the CTRL+Arrows I only use for that Quick mode feature.

 

7 hours ago, manterola said:

I would like to hear your thoughts.

I just tried to make sense of what you wrote about the tables, with one redefining the other, and kinda got a little lost. Anyway since the chart below shows the exact same ATASCII code for the CTRL+Arrows as what I had found for what should be the shifted (info must have been incorrect about shifted) non-shifted F1-F4 keys, then I can certainly see how the values shown in register CH must be getting converted to render the same ATASCII result, even though they are originally defined as different keys in the raw keyboard matrix. However this can't be the same thing that happens for the shifted F1-F4 keys which do entirely different things than the arrow keys. So I'm definitely a bit lost as to what needs to be done in order for the firmware to correctly capture the SHIFT+F1-F4 keys and react appropriately to them in the A8 Pico Menu.

 

Sorry I can't be of more help.

 

[dmsc]

Hi!

 

4 hours ago, manterola said:

$1C and $1D are just Ctrl+- and Ctrl+= (the arrows keys).

I read mapping the Atari, and other sources plus the little basic program in basic to check CH in Altirra emulating 1200XL with F1-F4 keys, and I think I understand what is going on.

 

The first table attached shows the CH content for the Fn 1200XL keys. For example, F2 is $04 and with Shift key is $44. Then looking the table in $FB51 (default table for atascii conversion in XL/XE models which is pointed by vector KEYDEF $79,$7A), you can see that code $8B is returned no matter if Shift is pressed. I also highlighted the Atascii code returned for F1, F3 and F4. 

But then those keys can be redefined and the default definition are taken from a table located in $FC11 (pointed by vector FKDEF $60, $61) which, for example, makes that F2 key $8B behave like $1D (no addic. keys) which is CursorDown, or alternatively to $8F (with Shift key pressed).

 

It is really easy to read the F* keys using the OS routines using the SUPERF memory location - just look at this code from the FastBasic editor, that handles UP/DOWN/PAGE-UP/PAGE-DOWN:

 

GET key

if key = $1D
 if peek(@SUPERF)
  '--------- Page Down ------------
  exec CursorPageDown
 else
  '--------- Down -----------------
  exec CursorDown
 endif
elif key = $1C
 if peek(@SUPERF)
  '--------- Page Up --------------
  exec CursorPageUp
 else
  '--------- Up -------------------
  exec CursorUp
 endif

 

Have Fun!

 

[dabone]

I did a quick mod to the back case with a hole and a button for the bootsel button on the pico.

Two different buttons, one is larger and may not fit depending on how calibrated your printer is, so print both, they are small.

 

Useful when you need to update firmware.

 

a8pico_back_v2-with hole.stl button.stl

Button Large.stl

Edited December 2, 2023 by dabone
Add File

[dabone]

Also, what about adding page skipping with left/right arrows and joystick?

And maybe a .. on top of the subdirectory listing to go back to the previous directory?

 

[ascrnet]

On 12/1/2023 at 12:18 PM, electrotrains said:

Have a look at the functions in the time.h API provided, something like this (untested)...

 

 

I performed several tests, placing the cycle as primary, secondary, or reversing the condition to use it in an IF. it still does not work as my logic indicates.

 

Attached is one of the many tests.

void __not_in_flash_func(emulate_standard_8k_timer)() {
	// 8k
	RD4_LOW;
	RD5_HIGH;
    	uint32_t pins;
    	uint16_t addr;
	absolute_time_t stopTime = delayed_by_ms(get_absolute_time(), 2000);
	
	while (1)
	{   
		while (get_absolute_time() < stopTime) {
			// wait for s5 low
			while ((pins = gpio_get_all()) & S5_GPIO_MASK) ;
			SET_DATA_MODE_OUT;
			// while s5 lo
			while(!((pins = gpio_get_all()) & S5_GPIO_MASK)) {
				addr = pins & ADDR_GPIO_MASK;
				gpio_put_masked(DATA_GPIO_MASK, ((uint32_t)cart_ram[addr]) << 13);
			}
			SET_DATA_MODE_IN;
		}
		RD5_LOW;
	}
}

Do you think you can use the Serial Wire Output (4 pins) to debug using a8picocart connected to the ATARI. Since you can't use the USB when it is connected.

 

On 12/1/2023 at 2:28 PM, Mq. said:

Good idea. I think it should be implemented in emulators (Altirra, Atari800) first. I don't know how to do it, and I don't know who can do it...

for altirra you must ask its creator phaeron by PM or using the thread he has for altirra 4.xx released, for atari800 a volunteer is needed.  😅

[Mq.]

Ok, thanks for looking on my case and analyze the Turbo 2000 cartridge image behavior.

 

Because the interest of such case is very poor, I decided to just install the physical switch in my particular A8PicoCart, which cut off the RD4 and RD5 signals.

 

I was talking all the time about that, because I thought that when I tell you it is good idea to give the users such switching possibility in official firmware, then it will be very usefull. The Turbo 2000 cartidge image is only example, and there are a lot of such images, but it's not the most important thing. When I instaled the switch on RD4/RD5 today, I'm playing with the A8PicoCart, and it is wonderfull function, exactly as I thought before. The switch has universal and very usefull function: you can turn off the cartridge, and you don't need to pull it out of the Atari, so you can use then a SIO2SD, FDD or anything you want.
Of course, my cartridge image of Turbo 2000 also 100% works.
I recommend!:-)

 

About emulating the cartridges timers in Altirra or Atari800, I will tell it the persons in Poland which deal a lot with such cartridges. I know some persons in Poland already did a new cartridges types for emulators before.

[electrotrains]

On 11/27/2023 at 1:36 AM, Fred_M said:

Because the costs are so low to make these A8PicoCarts, it seems like these would be a perfect alternative to make homebrew cartridges of single games. I created many cartridges with the GAL-chip, but these are getting harder to find and are becoming more and more expensive these days.

 

It would be nice if there would be a way to skip the menu when, for example, only a single file is present on the cartridge 😉

 

 

Okay, I've had a filddle with this, and rather than modify the existing firmware, please find attached a single cart version of the firmware.

 

If you put a file named "AUTORUN.CAR" or "AUTORUN.ROM" in the root directory, it will run automatically on power up. Identification rules for ROMs as described in the manual (standard 8K & 16K or XEGs is assumed depending on the file size). If you want a different type (e.g. 128K AtariMax) - use a CAR file.

 

It will leave any other files you have on the flash alone, so you can try out the new firmware and then flash the standard firmware back and be back where you started.

 

Didn't have time to do XEX files this weekend - maybe later if demand.

 

If you want to use this commercially to release games, I expect a donation to the project, and I will customise or remove the "A8PicoCart Loader" line if required 🙂

 

Why didn't I add to the existing firmware? I didn't want to make a mess since its not a trivial change to do nicely. This way I can go straight to a simple boot loader from the cart init vector (before the OS initialises the screen editor), so you don't get the "blue flash" when the cartridge starts. I've also recoded the Atari<->A8PicoCart interaction, so there is more hope it will work on an 400/800 since I'm not using Phi2 for the menu. There is also a bit less data (e.g. no ATR OS.ROM) so firmware might load fast enough onto the Pico such that a 400/800 doesn't need a manual push of the reset button.

 

Any feedback on whether this actually works on an unmodified 400/800 would be appreciated.

 

Regards,

 

Robin

a8_pico_loader.uf2

[mozzwald]

14 minutes ago, electrotrains said:

Any feedback on whether this actually works on an unmodified 400/800 would be appreciated.

I have a stock 400 with the original Atari 48k RAM upgrade. The current firmware in github works fine for me with one caveat, the screen is garbled at power up and pressing System Reset brings you right to the menu. No problems with search, navigation or loading files.

 

I just tried this new firmware and I get the garbled screen but hitting System Reset takes me to memo pad.

[electrotrains]

Okay, doesn't sound like I've improved things on 400/800 then 😞

 

Robin

 

[Fred_M]

2 hours ago, electrotrains said:

 

Okay, I've had a filddle with this, and rather than modify the existing firmware, please find attached a single cart version of the firmware.

 

If you want to use this commercially to release games, I expect a donation to the project, and I will customise or remove the "A8PicoCart Loader" line if required 🙂

 

 

Thank you Robin 👍👍👍

 

At the moment I do not have any plans to release software commercially, but you will never know If I do, I will make a donation (again) ofcourse!

 

I am creating some cartridges for myself and my friends (free of charge). I also made some labels (A4 paper) which can be used for the (original) picocard, the STL with no logo. I hope you do not mind

 

picocart_labels.pdf
 

 

Edited December 3, 2023 by Fred_M

[electrotrains]

@Fred_M you are welcome!

 

The labels are very nice. Would you mind if I uploaded them to the github so others can use them?

I might do another version of the STL without the cutout to match these labels better.

 

Give me a few more days to get any other feedback on the loader version of the firmware, and I will perhaps do a revised version. I might just put the firmware cartridge code back to the Phi2 version, if it doesn't help with the 400/800.

 

Btw - the loader version of the firmware is fully self contained - so you can program a fresh pico with it, use the USB mass storage mode to copy a CAR file to the device - there's no need to put the normal firmware on at all if it the multicart aspect is not desired.

 

Robin

[Fred_M]

1 hour ago, electrotrains said:

@Fred_M you are welcome!

 

The labels are very nice. Would you mind if I uploaded them to the github so others can use them?

I might do another version of the STL without the cutout to match these labels better.

 

Give me a few more days to get any other feedback on the loader version of the firmware, and I will perhaps do a revised version. I might just put the firmware cartridge code back to the Phi2 version, if it doesn't help with the 400/800.

 

Btw - the loader version of the firmware is fully self contained - so you can program a fresh pico with it, use the USB mass storage mode to copy a CAR file to the device - there's no need to put the normal firmware on at all if it the multicart aspect is not desired.

 

Robin

 

Hi Robin,

 

Ofcourse you can upload the labels to your github 🙂 I have used the label on the STL with the usb connector at the right side and it fits perfectly.

 

 

The A8picocart I have now, was given to me by my good friend @SenorRossie and already has the "normal" firmware on it. I have ordered a couple of picos and PCBs from China, hopefully they will arrive soon. I will try the new firmware tomorrow and do know I can test on various systems if you want feedback 🙂

 

Thanks again!!!

 

Fred
 

Edited December 3, 2023 by Fred_M

[Fred_M]

23 hours ago, electrotrains said:

 

Okay, I've had a filddle with this, and rather than modify the existing firmware, please find attached a single cart version of the firmware.

 

If you put a file named "AUTORUN.CAR" or "AUTORUN.ROM" in the root directory, it will run automatically on power up. Identification rules for ROMs as described in the manual (standard 8K & 16K or XEGs is assumed depending on the file size). If you want a different type (e.g. 128K AtariMax) - use a CAR file.

 

The Autorun-feature works great! Thank you Robin!

 

A.o. I tried a self-made megacart image (128k) of Bruce Lee Return of Fury and it loads perfectly! An autorun message is shown on screen for a very short time and then the game is loaded. The Megacart image of International Karate RCX2 does not run, but that is probably because the size of the game is too big (1 mb).

 

I can confirm that the autorun firmware does not work on the 400 and 800. I tried loading the rom of Centipede (1982, 8k) and it does load on my 130XE, but it does not load on my 400 and 800 PAL. The Memo pad screen is shown even when the A8PicoCart is plugged into them.

 

[manterola]

On 12/1/2023 at 9:17 PM, mytek said:

No actually they are completely independent keys from the arrows, even though both will move the cursor directionality and in single steps (BTW, the info I posted about the ATASCII equivalents for the Shifted F1-F4 keys yesterday must have been incorrect).

Here's an updated version of the definition table you posted tagged with the TK-II recognized functions of the Normal and Shifted F1-F4 keys...

 

 

I use the F1-F4 arrow equivalents (not shifted) to double step the cursor across the screen for faster movement by combining them with the original CTRL+Arrow keys. This mode is toggled by pressing ALT+Q, 'Q' as in Quick. Since they are all distinctly interpreted as unique key codes, alternating between the two gets rid of the normal key repeat delay when holding down a key, thus the cursor flies around the screen at a much higher speed (double the normal key repeat rate).

 

EDIT: For normal arrow related menu functions I stuck with the CTRL+Arrow keys, which the current A8Pico Cart firmware currently uses (well at least the UP and DOWN arrows that is). The F1-F4 equivalents to the CTRL+Arrows I only use for that Quick mode feature.

 

I just tried to make sense of what you wrote about the tables, with one redefining the other, and kinda got a little lost. Anyway since the chart below shows the exact same ATASCII code for the CTRL+Arrows as what I had found for what should be the shifted (info must have been incorrect about shifted) non-shifted F1-F4 keys, then I can certainly see how the values shown in register CH must be getting converted to render the same ATASCII result, even though they are originally defined as different keys in the raw keyboard matrix. However this can't be the same thing that happens for the shifted F1-F4 keys which do entirely different things than the arrow keys. So I'm definitely a bit lost as to what needs to be done in order for the firmware to correctly capture the SHIFT+F1-F4 keys and react appropriately to them in the A8 Pico Menu.

 

Sorry I can't be of more help.

 

I have modified the copy of the conversion table (from internal? code to ATASCII) so now it should work. Please try this latest version. This does not include the latest additions (like the autorun.car feature). 

a8_pico_cart.uf2

[+mytek]

4 hours ago, manterola said:

I have modified the copy of the conversion table (from internal? code to ATASCII) so now it should work. Please try this latest version. This does not include the latest additions (like the autorun.car feature). 

a8_pico_cart.uf2 191 kB · 1 download

Unfortunately I'm out of town until Wednesday night, but I'll be able to test this out the following morning. Thanks for persisting on this

 

I see that someone else downloaded this file, so perhaps it's someone with a TK-II in their system and they'll beat me on the test.

[ascrnet]

I continue to play with emulating those rare cartridges that catch my attention.

 

To make the timer for the T2000 I programmed it as an alarm, since the other way does not work for me, a little video.😁

 

Another support for Arab cartridges.

 

 

[a8isa1]

My soldering needs work but I have one of the XL boards built (minus the reset switch which arrives tomorrow).

 

I found Wrathchild's Quad Infocom ATRs work well in this medium.  Game saves are lengthy, about a minute, because of the slow flash memory but the feature does seem to work.

 

Jindroush's Z-machine generated ATRs don't work.   Is a workaround possible?

 

I've enclosed a generated ATR of Zork III as an example.   The ATR works in emulators and on my 800XL via SIO based drive emulators, FujiNet and AVGCart

Game r25 (860811) (z3_dd_ext_v1).atr

Edited December 6, 2023 by a8isa1

[akator]

I'm curious how others are using their A8PicoCarts.  Are you only using cart formatted files?  Is it your testing cart for new releases?  Perhaps you're only putting your favorites on it?

[bfollowell]

1 hour ago, akator said:

I'm curious how others are using their A8PicoCarts.  Are you only using cart formatted files?  Is it your testing cart for new releases?  Perhaps you're only putting your favorites on it?

I still use mostly my UltimateCart for the bulk of my multi-cart needs. I built mine as a cool little project and to have an extra multi-cart for use in one of my lesser used machines if needed. It's still an awesome little cart and was a cool, cheap little build project, but I'd never intended it to replace any of my other devices. I haven't really loaded mine up all that much yet. I won't try to fit my entire cart collection onto it, as it takes up more space then the PicoCart has available, so I'll probably try to put together a smaller, curated collection of my favorite carts; ones that I'm more likely to actually use on any given day. If there's room left over, I'll fill it with xex files.