Homebrew intellivision cartridges ?

[JohnPCAE]

Also make sure that your cartridge board is wrapping BC1, BC2, and BDIR back to the Master Component like other carts do. This is critical.

[JohnPCAE]

One other tip: run your code out of RAM if possible. I found that running my code from flash on a Raspberry Pi Pico wouldn't work. The problem is that reading a new page from flash introduces latency that was causing me to miss bus cycles.

[aotta]

The BDIR, BC1 and BC2 are wrapped back (i copied the schematic from the t-cart for wiring the signals to slot), but avoiding RAM would be a problem in my case, since i copied the Bin files to RAM in a 65535 uint array and used it to get 10 bits to write the bus in the DTB cycle... well, i've a lot to think about!

[JohnPCAE]

No, I mean run your code FROM RAM. Running it directly from flash might be causing you latency problems. For example, on the Pico my Intellivision bus code runs on core #1, and I designated that code as __time_critical_func, which causes the entire routine to be loaded into RAM at startup:

 

void __time_critical_func(core1_main()){...}

Edited November 12, 2022 by JohnPCAE

[aotta]

Now it's clear to me, but Teensy 4.x should have a default "FASTRUN" that works as the time_critical_func on the Pi.

Since Teensy has a 600mhz CPU and 200mhz GPIOs, i probably understimated the timing critical situations.

Now my first goal is made working the 16bit parallel reading (probably i miss some bits in muxing pad or ctl registers), so i can replace the bits ORing and ANDing and the single pinMode() redirection, that costs a lot of cycles, and for use your great "lookup" table for managing the bus cycle (i must invert the BC1 and BC2 bits too, i placed them in my board in different orders than you!).

I wonder if my latching logic is wrong too, i only use the lvc245 Dir pin to enter and quit to the intellivision bus, when you use others 245 for it.... may be i need do the same?

Thank you again for your  support!

[aotta]

Some progress, i think my cart write something to the intellivision bus... but not as it should do:

 

probably my write routine is not fast enough... i must change the single pins mode assignment and writing with the parallel gpio mode!

[JohnPCAE]

Or you might not be holding the data on there long enough. When I write to the bus with all 16 bits at a time, I then have to keep the data on the bus for at least 600ns before I set my data pins back to input. Oh, and I do reads and writes on multiple pins simultaneously for speed. In the ACC I do them 8 at a time and in the USB board I do them all 16 at a time. The important thing is to get all 16 data bits on the bus before other chips start looking for them.

Edited November 12, 2022 by JohnPCAE

[aotta]

Following your hints i get the 1k "Hello world"'s bin working! 

But other 8k  cart freeze after splashscreen (baseball one when players enter in the field, astromash after showing starred sky)...

Maybe i have to handle in some special way the SDBD cycle? at the moment my code only returns to DTB the word pointed in previous BAR/ADAR, but i'm not sure it's enough.

I'll start to write the "choosing bin file" and "rom mapping" routine too.

[JohnPCAE]

You only need to handle BAR, ADAR, DWS, and DTB. You can treat all others like a NACT. And you don't have to care about SDBD. One thing I do is detect MSYNC pulses and reset my internal variables, including setting my "previous bus state" variable back to NACT.

 

You're doing the right thing with DTB. On a BAR or ADAR, I prefetch the word at that address and on a DTB I put that word on the bus. In fact I handle BAR and ADAR in the same portion of code.

 

Try tweaking your timing: how long you hold the data on the bus for DTB and how long you wait for the address to be stable on BAR and ADAR. Maybe you're timing is marginal.

Edited November 13, 2022 by JohnPCAE

[aotta]

I looked at your ACC code, and i'm waiting 482 millis after wrote the bus, and 500 millis since 74ls245 latching before reading the bus.

Made small changes to timing but with no difference since now.

But, why you mentioned the DWS? I thought it's used only in writing to a device, so i don't care about it for my rom emulation.... i'm wrong?

[JohnPCAE]

Oh yeah, if you're only emulating ROM then you don't need to care about DWS (as long as you're not emulating something with RAM like Chess).

[aotta]

6 minutes ago, JohnPCAE said:

Oh yeah, if you're only emulating ROM then you don't need to care about DWS (as long as you're not emulating something with RAM like Chess).

interesting.... added to upgrade list! 

[JohnPCAE]

The waits that I'm doing are in nanoseconds, not milliseconds. A single NOP instruction on a Pi Pico running at 133MHz takes about 7.5ns.

Edited November 13, 2022 by JohnPCAE

[aotta]

My fault, sorry, i meant Nanoseconds. In Teensy there is the useful delayNanoseconds() function that i used.

 

[JohnPCAE]

I wonder if you're running into flash latency. Is your game stored in flash? I wonder if you need to first preload it into RAM.

[aotta]

No, i load game into a 128k array from sdcard, then read each word needed in DTB from the array at index [bus address].

I starting loading the array in the 8mb extmem, but it's a PSRAM so i avoid it for speeding up the reading.

I haven't yet done other test with timing, since i made the file selecting routine (it remain the "/.." handling..) and then i must manage the rom mapping (for now, i load only file smallest than 8k in the &5000-&6fff bank).

 

As i wrote, the code is on github if you find some times to have a look at it: https://github.com/aotta/RTO-Cart/tree/main/RTOCart

As you could see, i copied pieces of code from your ACC, but i give you the credits in the incipit

Edited November 13, 2022 by aotta
added note

[JohnPCAE]

Could it be the way you handle DeviceAddress? I set it by comparing the incoming address from BAR/ADAR against what is valid (5000-6FFF in your case).

[aotta]

i think the bin addressing is correct, but i noticed i have some DWS bus state in the $5000 range, and i don't know if i have simply to ignore them or (more probably) is a signal that there's an error....

the strange is that games seems start and freeze after few seconds, and testing baseball bin i noticed weird scoring and setting... could this be useful for understanding what's wrong?

[JohnPCAE]

Are you trying to log what's happening? That could be causing major latency problems (by the time you finish logging something like the bus state it could have changed, for instance).

[aotta]

No, i'm afraid it's not a latency problem, but i have some bits "floating" even in the bar/abar cycles.... maybe i have to mux in the right way the pin. Did you John pull-up or pull-down the GPIO connected to intellivision's bus? 

[JohnPCAE]

I actually neglected to set them, but the RP2040 datasheet says that the default state is pull-down. Which I think is best since that results in a default NACT state.

Edited November 16, 2022 by JohnPCAE

[aotta]

I had solution under my eyes, since Intvnut attached his mail in previous post dated 8 may 2020, but didn't read it with the attention due!!!

I needed to add writing bus in ADAR phase too!!!

Now i'll clean a bit the code and update it to github. And i'd start design the 3d model for the cartridge too...

 

[+BBWW]

Very cool stuff. I can barely find my foot in broad daylight. I love reading this stuff.

[aotta]

The cart looks for "samenaneofbin".bin cfg files for mapping, otherwise use the default map rom. I haven't yet tested all maps configuration, neither implemented the ram support (I'll start working on it tonight)

[aotta]

And now RTO-cart works with game with ram too!!

For anyone wants do himself an intellivision multicart, the project's files are updated on my github repository