Introducing picocart - it works

[speccery]

On 1/25/2023 at 10:18 AM, Archimedes5000 said:

The gerbers are still not in the Github Repository ? Is it possible to get them ?

Yes I can upload them, but my plan is to fix certain things first. The component labels were accidentally missing from the silk screen, and the SOIC-8 footprints were not of the wide variety, etc. Nothing that prevents getting the board working though.

[+arcadeshopper]

@speccery what are the memory specs on this board?  how much rom and grom can it simulate?

[speccery]

On 4/30/2023 at 6:50 AM, arcadeshopper said:

@speccery what are the memory specs on this board?  how much rom and grom can it simulate?

Sorry for the late reply, I haven't clearly been paying attention here. The microcontroller RP2040 chip itself has about 264k of RAM, so I think that carts at least around around 200k bytes can be served from RAM, be it ROM and GROM. In addition, the Raspberry Pico board itself has an external 2 megabytes of flash ROM, which I think is fast enough to serve GROM and but perhaps also regular ROM. It's been a while I worked on the code, need to check where it keeps the ROM contents. In addition to those memories, there is also a 16 megabyte external SPI flash chip. In practice this means that as far as GROM is concerned, there is no limit in practice. For ROM, it might be limited to the internal RAM size.

[speccery]

@arcadeshopper Hi Greg, a follow up question: I will need to do another spin of the PCB to fix the bodge wires. I have already done pretty much the work, but I am planning to swap out the external serial flash ROM chip and put in a SD card slot instead. While I am at it, I could also put in a pseudo static RAM chip. I have already those, if I remember they're 8 megabytes in size. It's a nibble wide serial chip, so might be a bit tricky but should be able to use that for cartridge ROM storage. What amount of memory you'd like to see?

[+arcadeshopper]

4 hours ago, speccery said:

@arcadeshopper Hi Greg, a follow up question: I will need to do another spin of the PCB to fix the bodge wires. I have already done pretty much the work, but I am planning to swap out the external serial flash ROM chip and put in a SD card slot instead. While I am at it, I could also put in a pseudo static RAM chip. I have already those, if I remember they're 8 megabytes in size. It's a nibble wide serial chip, so might be a bit tricky but should be able to use that for cartridge ROM storage. What amount of memory you'd like to see?

Would love 8mb. that would let us load some of the video files that wont fit in any other carts now. anything from 1mb up would be great for ROM Space, GROM I think you already said would be the max capable right?

 

[JasonACT]

In your opinion, would you add 3 pull-up resistors on the ~enable pins of 3 of the '245 chips for when the Pico is still resetting?

Edited May 9 by JasonACT

[speccery]

On 5/9/2023 at 2:21 PM, JasonACT said:

In your opinion, would you add 3 pull-up resistors on the ~enable pins of 3 of the '245 chips for when the Pico is still resetting?

Yes good point, in fact one of the mods I already have done for the board is this. Especially important for the '245 driving the TI's data bus.

[JasonACT]

It, indeed, does work...  I can add ~200KB of RAM to my TI-99 (which arrived from Texas!! last week, to the ACT of Australia...)  I only used a few concepts from here though...  Mainly, switching 3 x 8 bit bus reads.  This device includes 32KB expansion memory, 24KB DSR (upper 4KB paged RAM for DSK access and more - a spare serial port is available, but was used while debugging this thing), PWM sound output (bottom right of the board, a few analog components - this Pico implements a Speech Synthesizer - the MAME code - but I've not got it working 100% yet, Parsec and Alpiner work most of the time, TI-EXB can't look up words though)..  Transistors (FETs) control: ready, load, extint...  Not used yet, but ready should fix the speech by allowing the correct delays needed.  'Load' interrupt should allow me to "slide in" a custom routine (temporarily "sliding out" any user's vector) to get console CRU accesses to be overridden for USB keyboard and Playstation controller "patches" to the console's key-scan routine...  A USB keyboard/joystick/mouse device for a completely unmodified TI-99 console!  We will see!

 

There's a few 74LS signals I'm directly connecting to the Pi-Pico (Ebon Upton says the Pico is ~4.9v tollerant, look it up before flaming me!  The transistors are used on signals that are actually pulled up to 5.0V which he says isn't supported) the other's should be ok, and this saves on a AU$5 part - making this device cheap-as.

 

 

I do not recall though (35 years ago) there being colours (colors, for non British colonies) in the text output - which, incidentally,  makes Parsec (which works too) look pretty cool.  Is this something the NTSC consoles did?  Or is my 2010 Samsung plasma (try getting a recent display to accept composite input!) doing it wrong?

[Tursi]

Nah, that's standard for NTSC  Congrats!

 

[Artoj]

Great work! Speccery and JasonACT it looks like I don't need to create a special side port Mini card as you guys have developed it, in front of my eyes. This card  should plug into the Mini expansion system with out a hiccup. I have a Pico I was going to use for my development learning curve, I think I might reserve it for your new boards. Thanks again, looking forward for the next few chapters on the Picoart, regards Arto. 

[speccery]

On 6/8/2023 at 3:28 PM, JasonACT said:

It, indeed, does work...  I can add ~200KB of RAM to my TI-99 (which arrived from Texas!! last week, to the ACT of Australia...)  I only used a few concepts from here though...  Mainly, switching 3 x 8 bit bus reads.  This device includes 32KB expansion memory, 24KB DSR (upper 4KB paged RAM for DSK access and more - a spare serial port is available, but was used while debugging this thing), PWM sound output (bottom right of the board, a few analog components - this Pico implements a Speech Synthesizer - the MAME code - but I've not got it working 100% yet, Parsec and Alpiner work most of the time, TI-EXB can't look up words though)..  Transistors (FETs) control: ready, load, extint...  Not used yet, but ready should fix the speech by allowing the correct delays needed.  'Load' interrupt should allow me to "slide in" a custom routine (temporarily "sliding out" any user's vector) to get console CRU accesses to be overridden for USB keyboard and Playstation controller "patches" to the console's key-scan routine...  A USB keyboard/joystick/mouse device for a completely unmodified TI-99 console!  We will see!

Nice work! I am curious, did you use my firmware or you rolled your own?

Also interested in the source you used for the expansion port edge connector  

I have been thinking about creating a board similar to the ET-PEB I did earlier, but using the Raspberry Pi Pico instead of the LPC1347 and that would enable creating it without the CPLD, making a simple board, pretty much like you did. Have you made the schematics available?

[JasonACT]

I wrote my own firmware, when I started I had plans to do a lot more than just serve up memory, so I needed to take CRUs into account.  I should probably have looked at yours, there were a few things I missed early on regarding writes (which obviously you don't need to run cartridges, so the firmware from my photos above had some unnoticed flaws).  The past few days I've been fighting CRU reads (9900 reading, which has no strobe, so needs some pretty good timing) and learning the hard way that *LOAD needs to be held low throughout the R13/R14/R15 writes to the new WS.

 

There were other stumbling blocks too, once I got *LOAD working well, I added more Pico code to offload some calculations for my TI interrupt - but even though my function is RAM resident, the first pass through the code shows up on the analyser as a short signal on the first byte read of the >FFFC WP making it unreliable.  I'm guessing the RAM to Cache transition in the Pico takes a bit of time, because once the code has run once, the signals return to the length I need.  I think I'm at my absolute limit now with what can be done, with my revised code, but it is switching a small part of high memory to a new block (byte array) while my int-code runs.  It's also firing *LOAD (I think) fairly reliably when the keyboard CRU bits are being read (and a key is pressed on the USB keyboard...  No need to interrupt if no key is pressed).

 

My schematics are basically what you did, except I'm using a 74HC138 to select the '245s.  Oh, and I've got the Pico's D0-D7 connected to them so reading/writing is simpler.  Since they say the analog capable Pico pins are not at all ~4.9v tolerant, I'm using those as the select lines on the '138 and the last one for audio out.  The audio circuit is here:

https://github.com/rgrosset/pico-pwm-audio

 

One thing I would change, is not dragging the audio output trace across every digital signal on my board, it's very sad and I may cut the trace and use some coax.

 

The edge connectors are available here:

 

https://www.ebay.com.au/itm/143868496672

[JasonACT]

I turned off the Speech Synth code, it seems having both that (quite large) library and the USB Host library (also large) running at the same time causes the small CPU cache to change unexpectedly and slow down my main loop serving the memory bus.  Quite unstable.  But in doing that, I was able to get my LOAD interrupt working and I now have the USB Keyboard and the Playstation 4 controller joystick working (I don't have 2, but I'm sure a 2nd would work concurrently too).  I can easily detect all the console's STCR instructions (reading the keyboard/joystick positions) but alas, the TB instruction for the AlphaLock never gets detected (not sure why yet, the analyser shows it easily detecting the STCR quite early in the cycle on bit 1).  I've not seen any difference between the two in any diagrams I've read previously...  Oh well, if I need Caps-Lock, I can use the console's keyboard.

 

It is starting to really show the limitations of the Pico though.  Maybe there's a way to keep my main loop in cache and let the other boring stuff run from RAM or flash?

[JasonACT]

Tease of what has worked here:

 

[speccery]

3 hours ago, JasonACT said:

It is starting to really show the limitations of the Pico though.  Maybe there's a way to keep my main loop in cache and let the other boring stuff run from RAM or flash?

You have a great project going on for sure, congrats!

 

Are you using both cores of the Pico? In my code I have one core serving the TI bus and doing nothing else, while the other core is then free to do whatever.

I guess running from RAM should run as fast as from the cache, although I haven't studied this part yet. 

 

The Pico apparently overclocks really well, I have a Pico System from Pimoroni and that runs at 250 MHz stock, their firmware always keeps it overclocked. This would nearly double the performance. I wrote a TI-99/4A emulator for the Pico System using their libraries, so that is running at 250MHz. I have not played with clock settings myself though.

[JasonACT]

It's late here in Aus...  Sleepy time here... but yes, mine runs on 2 cores and @250MHz...  From what I'm reading, the 16KB CPU cache (XIP) is faster than RAM, can be turned off, can be loaded with your particular 'important' function, but is pretty non-standard.  Otherwise, the "other core" can disrupt the one you're using for very important stuff.

 

I would write to Earl (I'm using the Arduino distribution) but I really don't think he will be interested in this niche requirement.

 

He has left open my request for USB host on the native USB port (rather than what's the default - PIO USB bit banging for host) so who knows?

[speccery]

Just now, JasonACT said:

It's late here in Aus...  Sleepy time here... but yes, mine runs on 2 cores and @250MHz...  From what I'm reading, the 16KB CPU cache (XIP) is faster than RAM, can be turned off, can be loaded with your particular 'important' function, but is pretty non-standard.  Otherwise, the "other core" can disrupt the one you're using for very important stuff.

 

I would write to Earl (I'm using the Arduino distribution) but I really don't think he will be interested in this niche requirement.

 

He has left open my request for USB host on the native USB port (rather than what's the default - PIO USB bit banging for host) so who knows?

Thanks for the feedback. I've not used the Arduino distribution, I went with the Raspberry Pico SDK directly. I didn't realise you're already running at 250MHz, I'm currently still at 133MHz for ROM and GROM services.

[JasonACT]

New day, new ideas...  Last day of my short holiday though.

 

I went with Arduino because it has 2 USB stacks to choose from, and with a very small patch can enable the host mode on the hardware.  Without this small change, it will default to PIO mode USB host emulation - which I didn't want, since I would be wasting 2 extra DIO lines and would need a USB socket - when there's one already there.

 

Anyway, this morning I cleaned up the code, added "goto" statements wherever I could to have 1 common ending for almost everything (waiting on one of A15, *WE or *MEMEN), changed the 'inline' spec on most of the sampling functions (the ones with more than 1 line of code) and made them RAM resident instead.  I figure one copy in the cache is better since it's only 16KB.  I reckon I've saved half a KB, maybe more, there were quite a few "NOP" waits of 84ns (21 NOPs in a row) that are now gone, which were taking up a lot of space.

 

Anyway, speech and USB devices are now working together nicely.  TI-EXB can read the speech ROM and speaks too, since I coded the *READY line around that library's access.  I just have to figure out why the CRU Test Bit instruction isn't being detected for AlphaLock.  Then steal a Jedi's code-repo to implement a DSR ROM and see if DSK access works while the TI is running (at the moment, it only loads a cartridge while the TI is powering up).  I'm hopeful though, when DSK is being accessed, the speech and USB routines will not be executing at all - mostly all running from core 0.

 

(Still fantasising about the WiFi on the Pico.)

[JasonACT]

So, "Test Bit" - the TB instruction...  I do catch it and I raise the LOAD signal "before it ends" [TI would argue I didn't] (the logic analyser shows the address bus changing to the CRU address and about half way through that cycle, I've signalled LOAD)...  But it still runs the JEQ instruction @>043C and I end up not being where I need to be for the LOAD interrupt.

 

Meh, I added a couple if lines of code to detect this and reset the R14 return address to be >043C so it will run JEQ again (which also allows me to detect the TB instruction and modify the R15 status register copy).

 

I don't hate it, I don't like it, it works pretty well and I can't think of another solution where you *need* to know the CRU address but then it's too late to fire LOAD.

[speccery]

On 6/13/2023 at 9:58 AM, JasonACT said:

So, "Test Bit" - the TB instruction...  I do catch it and I raise the LOAD signal "before it ends" [TI would argue I didn't] (the logic analyser shows the address bus changing to the CRU address and about half way through that cycle, I've signalled LOAD)...  But it still runs the JEQ instruction @>043C and I end up not being where I need to be for the LOAD interrupt.

 

Meh, I added a couple if lines of code to detect this and reset the R14 return address to be >043C so it will run JEQ again (which also allows me to detect the TB instruction and modify the R15 status register copy).

 

I don't hate it, I don't like it, it works pretty well and I can't think of another solution where you *need* to know the CRU address but then it's too late to fire LOAD.

To clarify my understanding - you are on purpose invoking a LOAD between TB and JEQ, is that it? To override the read of the ALPHA LOCK with your own data? Nice one!

[JasonACT]

Yeah, that's right.

[JasonACT]

I must be doing something right, if I can load and save from DSK1...

 

[JasonACT]

My Saturday night update - I'm on a knife's edge...

 

"SAVE" and "LOAD" (PROGRAM files used for basic programs and Tunnels of Doom files) worked pretty well straight away, I zap the data blob into/out-of my ~20KB DSR paged RAM and get on with things.  But when I started to test Fixed and Variable files (which require much smaller record based accesses) things got harder.  I wrote a basic program (started out as one to read the directory - and that wasn't too bad - got it working quickly) but then moving onto other real files with records, I had an error with "IF EOF(1)THEN" <- where did the space before "THEN" go?  An hour later, TI-XB showed it was working properly (along with other emulators having the same issues with EOF in normal BASIC).

 

I moved onto Editor/Assembler (the editor) for testing F/V80 files.  Turns out it doesn't close them when it's finished reading!  Of course my DSR detects if you try to open the same file twice, and returns an error, when you try to reload it.  Sigh.

 

Then, my first attempt with these things (\x07TIFILES) was trying to be really smart - this is a 250MHz Pico!  I can open/seek/read/write/close on every operation requested (power safe, atomic operations)...  But NO!  That slows things down quite a bit (acceptable though, it if worked) but it also thrashes the Pico's CPU cache and causes instability (again).  Back to unsafe methods, let the Pico libraries do their thing, and it is now working.  I sometimes get a USB keyboard key stuck down (this is a problem in the "editor" if you haven't saved recently).  I thought I'd fixed that, something I need to talk to a Jedi about.

 

Other than that, I implemented the TI-Joystick 8 directions using the Playstation 4 analog joystick (I only had the digital pad working before) and I locked out the digital pad to 4 directions only...  Now Alpiner, which allows diagonal movement, works pretty well with the analog stick.  Parsec, MunchMan and Slymoids work much better with the digital pad (it locks in a direction, if you go diagonal, the new signal takes priority - so if you are going left and then left-up - up takes over, etc.)

 

Am I cheating?  A lot of these games were coded to be harder by making you look like a fool when a diagonal would be discarded leaving you hanging.  I think I'm good.  Except for that knife which I can feel is digging in.

[JasonACT]

3 hours ago, JasonACT said:

I sometimes get a USB keyboard key stuck down (this is a problem in the "editor" if you haven't saved recently).  I thought I'd fixed that, something I need to talk to a Jedi about.

I still need to post my code fixes to the USB keyboard routine I shamelessly stole, there is an issue easily reproduced by: "press shift, press backspace, release shift, release backspace".

 

But in this case, simply moving the wireless keyboard receiver into the same room as the Plasma TV, while my TI-99/4A is on the workbench in the room 10 feet away has fixed this particular key-repeating issue.  I can't believe it either.  Gremlins!  Lucky for me it was starting to happen regularly enough for me to debug and see it wasn't a corrupt emulated CRU matrix - but simply not having a key release reliably detected.

 

Slowly.. slowly.. getting there.

[Tursi]

Can you tell me more about your keyboard/joystick routines? Are you overriding the data bit from the side port when you see the CRU commands?