A8PicoCart - UnoCart on a Raspberry Pi Pico

[Wrathchild]

that limits you to carts, plus the menu ROM has other stuff going on it needs that you wouldn't necessarily mount with an 8K cart. 

Edited November 27, 2023 by Wrathchild

[Mq.]

5 hours ago, ascrnet said:

On 11/26/2023 at 1:12 PM, Mq. said:

I think it is hard to say when there is the moment the cartridge already completely loads all the stuff to the RAM. So this is the cause it is good idea for on demand button or waiting few seconds. Second cause to do it this way is the ability to see for a while the original message "turn off the cartridge".

 

I performed several basic tests by turning off the RD5 after the cycles that the firmware has for the 8k cartridges but it returns me to basic. so you are right you have to find a way to determine when it was all loaded. 😅

I told you:-) You must wait a few seconds (about 2-5 seconds for example) and then turn off RD5 (pull down).

 

5 hours ago, ascrnet said:

On 11/26/2023 at 1:12 PM, Mq. said:

The image of Turbo 2000 which I attached works ok as car image prepared as both of them. It just requires double the image for 4k or quadruple it for 8k.

 

I find your image strange because it is set to 8k but it is really 2k. you say that the 2k is repeated to form 4k or 8k on the actual cartridge?

In this case in the original cartridge there were physically an eprom 2kB. But the address lines A11 and A12 from Atari cartridge port was not connected at all. Such construction causes that from the Atari side this 2kB EPROM is visible as duplicated four times in area $A000-$BFFF, because whatever you set on A11 and A12 lines, the EPROM always will give you the same result. When you run that 2kB image in Altirra as 8kB standard (type 01) then Altirra do it correctly and you will see it as I described above. Then you can save the image as "car" file from the Altirra and you have correct 8kB cartridge image. I attach here such ready to use image. Actually I was using only such "car" image in the A8PicoCart.

T.2000.car

Edited November 27, 2023 by Mq.

[ascrnet]

On 11/27/2023 at 4:13 PM, Mq. said:

I told you:-) You must wait a few seconds (about 2-5 seconds for example) and then turn off RD5 (pull down).

Of course, I thought about turning it off after the while copying the cartridge contents to the ATARI but it's so fast that it comes out to BASIC.

Now I will try using a pause with the sleep_us command.

 

On 11/27/2023 at 4:13 PM, Mq. said:

In this case in the original cartridge there were physically an eprom 2kB. But the address lines A11 and A12 from Atari cartridge port was not connected at all. Such construction causes that from the Atari side this 2kB EPROM is visible as duplicated four times in area $A000-$BFFF, because whatever you set on A11 and A12 lines, the EPROM always will give you the same result. When you run that 2kB image in Altirra as 8kB standard (type 01) then Altirra do it correctly and you will see it as I described above. Then you can save the image as "car" file from the Altirra and you have correct 8kB cartridge image. I attach here such ready to use image. Actually I was using only such "car" image in the A8PicoCart.

thanks for mentioning it, indeed altirra fills with the same content to form the 8K. Surely this was done to address these cases.

 

A8PICOCART does not have this, but it does have support for 2K using type 57.

[Mq.]

57 assigns 2k image from $B800 to $BFFF. It is ok when such 2k cartridge has a run address between that addresses values. I didn't analyse it, but I think the early cartridges was designed such way that the most significant address lines was unconnected, to intentionally duplicate the image in all cartridge space. Such design give you start address at $A000, and the header on the end of cartridge space. Today from designer point of view I think this is good and that is good. As someone designed the hardware then he designed software too, and it just works. The problem (or rather case) is today when we try to emulate that old constructions, or we are building multicartridges to running everything in one device.

[Wrathchild]

The T.2000 basically copies and transfers control to code at $700 (up to $EFB) so realistically this could be offered as an option on the menu and this code made part of the Menu ROM image and when chosen does the same thing in the same way the XEX loader is, i.e. no need to mount a CAR image for this.T.2000.XEX

Edited November 28, 2023 by Wrathchild
added XEX

[Mq.]

@Wrathchild yes I know how it works, but you completely misunderstand the idea of running original ROMs. Ofcourse when we look at this from your point of view, then there is no sense to running any games from cartridge images, because every of them are available as xex files too:-)

 

I think nowaday we already have any games and other software runnable by any methods from any devices. But the fun for me is to run the cartridges images and feel it like I remember it from childhood.

I have many of different cartridges, a lot of games and software on them, sometimes I'm building old constructions like in 80s (for example cartridges like T.2000). But I interested in A8PicoCart, because I feel something magical when I run the "car" images from A8Pico. I don't know what is doing this feeling, but I like it:-)

 

But by the way: thank you for this xex, it is nice work.

[Wrathchild]

you get me wrong, games like the XE Cart Ballblazer are basically 'copy to RAM' games, so I'm not against that.

When I first mentioned it this was because I thought you had game titles within the cart. I now learn this is not the case.

From what I see though this code is OS dependent with direct calls ($E486, $EF8E, $F2B0, $F2FD, $FDFC).

So is it the bootstrap code for loading from an actual fast-tape device? If so then having a hot-key / menu option for that in A8PicoCart would seem a good way to install it.

I'm not sure the XEX is appropriate to use on the A8PicoCart as it conflicts with the XEX loader code itself (although could be relocated with Exomizer).

[dabone]

Thanks for this, it works great and is dead simple to build.

 

(And I got to put my new Bambu printer to work)

 

 

[Wrathchild]

They look great! Especially with the case using my football team's colours.

Chances are you're not in the UK but it you were then would buy one from you 😃

[electrotrains]

@dabone your boards (& shells) look really good!

 

If you're selling them for $15 I guess you're not going to be doing much more than covering your costs & time, but can you consider making a donation to the project and including that in the total selling price, rather than leaving it to your purchasers to donate?

 

That applies to anyone doing a run of boards for sale - please consider making a donation to the project (via the button on the github page) - I spent a good number of evenings writing the software, testing and making the cart shell design and while I'm not doing this for profit, its good to have a little money in my paypal account for when I'm gripped by the next idea for a project.

[dabone]

Ok, I'm asking $26 shipped in the USA (USPS Priority Mail).

 

I guess $36 for each, and I'll shoot the extra $10 over to the creator.

And, yeah I'm not really making anything off these after shipping, time, solder, cleaning solution for the ultrasonic, filament, super glue, electricity, etc.

 

 

[Mq.]

16 hours ago, Wrathchild said:

So is it the bootstrap code for loading from an actual fast-tape device? If so then having a hot-key / menu option for that in A8PicoCart would seem a good way to install it.

This cartridge was dedicated to load the tapes saved in turbo system. Such turbos was mounted as upgrade for original tape recorders. The games on tapes in turbo system was a few times shorter than normal original system of recording data to the tapes, so loading time was a few times shorter. Turbo system need two parts: electronic modification of the tape recorder, and a special files loader. Such loader was possible to load from tape first as a normal standard file, then next you was able to load the program (eg. game) in turbo system loading mode. For improve all that system, there were the cartridge with loader, so you can start this loader from cartridge, and then immediatly load games from tape in turbo mode.

16 hours ago, Wrathchild said:

I'm not sure the XEX is appropriate to use on the A8PicoCart as it conflicts with the XEX loader code itself (although could be relocated with Exomizer).

Nevermind🙂 I thanked you for the xex file to load it from any devices, unrelated to the topic of A8PicoCart.
I'm talking about this cartridge only for purposes of running it exactly as I run it in 80s.This has no logical or sensible justification🙂. I just want to feel like I'm back in the 80s. That's why I'd like to flip the switch when the program in the cartridge asks for it🙂.

[Mq.]

Additional info for turbo system which I described above. In the 80s in the central Europe like Poland, Czechoslovakia etc., the tape recorders were very popular and they are main data containers (the tapes). Disk drives was very expensive here, so they were very rare, and everyone was dreaming of them:-) Original system of tapes recording in Atari was very slow, and the games loading took a long of time. That situation caused the people was designing upgrades for tape recorders to change the recording system for better and quicker, as the systems used on ZX Spectrum or Commodore. There were a lot of such systems for Atari (eg. Turbo 2000, Turbo AST, Turbo Blizzard, Turbo 6000 etc.), so today many people like to preserve them as cartridges images, and sometimes we like to turn it on one more time as a kind of journey to the past.
Ofcourse today when I want to play the game, then I don't load it from tape recorder:-) We are the part of the today civilisation, so we have today everything the same as any people in the world:-) But I remember the sound of the tapes with the Atari games from childhood, and I like it so much, that sometimes I just start this sound and listen it on the headphones for specific pleasure:-)

[manterola]

On 11/20/2023 at 12:56 PM, mytek said:

Be nice to also use some of the PS/2 navigation keys (Home, End, Page-up, Page-Down, ect.) in TK-II for some of this as well.

 

Here's what I did for SDrive with a crude byte swap in the original program...

 

 

Notice also that the escape key is used differently, with 'F' being used for search instead, and escape sending you back to the parent directory.

 

Alternative TK-II sdrive.atr

 

Here are the Atari key code equivalents for those PS/2 navigation keys.

I created a new A8PicoMenu rom which (supposedly) adds support for the PgUp and PgDn keys in TK-II. I have no way to test this, so please, check the added functionality.

It is basically the same menu program that I uploaded before except for this addition. If it works, I can add support for "home" and "end" keys, later.

a8_pico_cart.uf2

Edited November 29, 2023 by manterola

[+mytek]

14 hours ago, manterola said:

I created a new A8PicoMenu rom which (supposedly) adds support for the PgUp and PgDn keys in TK-II. I have no way to test this, so please, check the added functionality.

It is basically the same menu program that I uploaded before except for this addition. If it works, I can add support for "home" and "end" keys, later.

I'll be testing this a bit later today and get back to you. Thank you for trying to integrate the special functionality.

[ascrnet]

On 11/28/2023 at 4:35 PM, ascrnet said:

Now I will try using a pause with the sleep_us command.

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.

[+selgus]

multiple post

[+selgus]

multiple post

[+selgus]

On 11/22/2023 at 11:15 AM, mytek said:

I've never done it myself. Only came across the information that I linked to after seeing the discussion about beveling the edge in this thread and only gave it a cursory glance. Probably needs to be read in more detail and perhaps if not clear contact JLCPCB for more info.

Here is a photo of gold fingers plus 30 degree bevel vs normal, using JLCPCB.. I've done a few different boards and tried out the different options..

 

[+mytek]

22 hours ago, manterola said:

I created a new A8PicoMenu rom which (supposedly) adds support for the PgUp and PgDn keys in TK-II. I have no way to test this, so please, check the added functionality.

It is basically the same menu program that I uploaded before except for this addition. If it works, I can add support for "home" and "end" keys, later.

a8_pico_cart.uf2 191 kB · 2 downloads

Unfortunately this new firmware didn't work for Page-Up and Page-Down with a PS/2 keyboard via the TK-II. I'm assuming that if you have a directory of files that exceeds the screen length in the menu you can jump between the file listing 'pages' with the Page-Up and Page-Down keys.

 

I suspect that there was a misunderstanding as to the key codes involved. I was referencing what key codes would be produced when running the following program.

10 PRINT PEEK(764):GOTO 10

Referencing the chart I included in this post...

764 2FC CH
In COMPUTEt's Third Book of Atari, Orson Scott Card explained
the keyboard and how to read it using the CH register.
The values listed as "internal code" in Appendix 10 are not the
same as those produced at 764. The internal code is the order
the characters are stored in the character set. The keycode re-
llected by 764 is the hardware code, which is altogether dif-
ferent for no reason I've been able to ascertain.

 

That code is the complete key code incorporating the SHIFT and/or CONTROL key influence where applicable.

 

There's probably another register that can be used for reading the raw keycode without the influence of either the SHIFT or CONTROL key.

 

Anyway the codes used for the Home, End, Page-Up, and and Page-down keys are just shifted equivalents to the 1200XL F1-F4 keys. So if you have a 1200XL that can also be used to verify.

[+mytek]

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.

[spicyjack]

5 hours ago, mytek said:

The keycode re-
llected by 764 is the hardware code, which is altogether dif-
ferent for no reason I've been able to ascertain.

That's because the Atari doesn't come with an "ABCDEF" keyboard.  The first mechanical typewriters had an "ABCDEF" layout, but it didn't last long.

 

The scan codes are generated based on how the keyboard electrical matrix is laid out by the PCB designers, while the order of letters in the English alphabet predate computers by a few years.  Quite a few years.

[+Stephen]

24 minutes ago, spicyjack said:

That's because the Atari doesn't come with an "ABCDEF" keyboard.  The first mechanical typewriters had an "ABCDEF" layout, but it didn't last long.

 

The scan codes are generated based on how the keyboard electrical matrix is laid out by the PCB designers, while the order of letters in the English alphabet predate computers by a few years.  Quite a few years.

This has nothing to do with ASCII values vs alphabetic number position.  The codes for certain ranges were shifted.  It came down to lowering the transistor count in the custom chips, and how bits were shared for either uppercase vs lowercase, or different colour register assignments being made.

[manterola]

13 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.

Thanks, this is very helpful. The asm code for the menu reads from CH and then uses a table to look for the ATASCII code for that internal code (my understanding is that XL/XEs include that table in ROM). Anyway, I will try using those codes provided by you, since I don't have a 1200XL either, and the ATASCII tables that I found using a quick look in archive.org don't include the Fn keys. 

[+DjayBee]

29 minutes ago, manterola said:

Thanks, this is very helpful. The asm code for the menu reads from CH and then uses a table to look for the ATASCII code for that internal code (my understanding is that XL/XEs include that table in ROM). Anyway, I will try using those codes provided by you, since I don't have a 1200XL either, and the ATASCII tables that I found using a quick look in archive.org don't include the Fn keys. 

Although this probably will be of no help regarding special keys on TK-II-connected keyboards, some logic to use the OS-mapping tables from CH to ASCII:

In OS-A and OS-B the table is located at the documented address $FEFE.

XL-OS added a zeropage variable KEYDEF=$79 which points to the (differing) OS-location of this table.

 

Therefore check if KEYDEF and KEYDEF+1 are =$00. If so, use $FEFE otherwise use the location in KEYDEF.

 

I usually do it this way (with self-modifyng code):

 

KEYDEF	EQU	$79
keytab	EQU	$FEFE

	lda KEYDEF+1
	beq noxl
	sta keytbl+2
	lda KEYDEF
	sta keytbl+1

noxl
;	go ahead

; access translation table
keytbl
	lda keytab,x
	rts