StrangeCart

[Tursi]

20 hours ago, speccery said:

Thanks for sharing the details. It does look feasible without any tweaks.

Let me ask a (stupid) question, is the cartridge image for the demo readily available somewhere to test with?

 

All of this makes me wonder how fast the StrangeCart can actually load data from the flash chip, i.e. what would be the latency from address setup to data. It looks like it can't do it in realtime, but I need to measure that. I will try to setup a test scenario, using your code:

    MOV R0,*R3          * change page on cart
    MOVB *R1+,@>8C00    * read data into VDP memory

The question becomes how would this need to be altered (if at all) to support the game. The MOVB *R1+,... is tricky since the full address (R1) will only be know during the actual fetch, and it may be that this is where things fall apart. However, if the returning garbage for the first two bytes does not matter, this might work as is. 

 

Yep, it's here on AtariAge.  First post!

 

The demo was written before I figured out the flicker, so you can really see the difference with and without F18A GPU support.

 

As for performance, since it's just copying the graphical data into the buffer for the still frames, you might be able to visually see the latency, but it shouldn't break the code.

 

[Asmusr]

@speccery I think the Second Processor version of Elite could be an interesting project for the StrangeCart. If the StrangeCart could run an 65c02 emulator with 64K RAM, all that we would have to implement on the TI side would be the commands to read the keyboard, draw a line, etc. and the latter could be speeded up by the StrangeCart generating an unrolled program in cartridge space. It's still a big project, but it sounds a lot more doable using the StrangeCart than converting the entire source code to 9900 assembly, which would also end up being very slow.

[speccery]

On 9/22/2022 at 8:50 PM, Asmusr said:

@speccery I think the Second Processor version of Elite could be an interesting project for the StrangeCart. If the StrangeCart could run an 65c02 emulator with 64K RAM, all that we would have to implement on the TI side would be the commands to read the keyboard, draw a line, etc. and the latter could be speeded up by the StrangeCart generating an unrolled program in cartridge space. It's still a big project, but it sounds a lot more doable using the StrangeCart than converting the entire source code to 9900 assembly, which would also end up being very slow.

That's an interesting idea! The 64K RAM requirement is not a problem. Running the 65c02 at 3MHz as found in the second processor is an interesting challenge, but should be doable.

As described in this post, the StrangeCart can run TMS9900 at near 9MHz without spending too much time in optimising the code. Thus I believe it would be able the 65c02 second processor at 3MHz, since that's a much simpler device to emulate than the entire TI-99/4A. @Asmusr If you're interested in playing with this I'd be happy to send you a StrangeCart, just let me know.

 

In general I have a few boards available (bare PCBs no case) so if people here are interested in buying some of these please let me know.

[Elia Spallanzani fdt]

isn't it easier to emulate the z80 and run the version for spectrum or msx, which have the same resolution as ti99?

[Asmusr]

3 hours ago, Elia Spallanzani fdt said:

isn't it easier to emulate the z80 and run the version for spectrum or msx, which have the same resolution as ti99?

The StrangeCart cannot do any I/O on its own, e.g. draw on the screen or read the keyboard, so if you emulated a normal version of Elite on the StrangeCart, you would have to find a way to delegate all I/O to the TMS9900, which would be both difficult and slow. The 2nd processor version of Elite is designed with the separation of responsibility between co-processor and host processor in mind, which is why it looks like a better choice.

[Asmusr]

On 9/25/2022 at 9:32 AM, speccery said:

@Asmusr If you're interested in playing with this I'd be happy to send you a StrangeCart, just let me know.

Thanks for the offer, but if I was going to work on this, which is not entirely unrealistic, I wouldn't start with the hardware. My first step would be to set up the emulation of the 65c02 on a PC and somehow connect it to my TI-99/4A emulator. I haven't studied how the tube communication works on BBC micro, and making that work with the TI would be the next step. Getting to a point where you could see the 65c02 sending command to the TI would be the first milestone. Would it be considered cheating and not a native TI game? I don't think so if all you needed was a cartridge, but would it make sense to create a StrangeCart just for releasing a single game? Would it require 32K on the TI side? Probably yes.

[speccery]

1 hour ago, Asmusr said:

I don't think so if all you needed was a cartridge, but would it make sense to create a StrangeCart just for releasing a single game? Would it require 32K on the TI side? Probably yes.

StrangeCart has its own file system which can be updated quite easily updated, it has 16 megs of flash storage on-board. You wouldn’t create a bespoke StrangeCart, but just load the game on the flash. StrangeCart can offer RAM for the TI from the cartridge space, so if a paged cartridge with RAM and ROM pages from TI’s perspective is an option, it could work without memory extension.

[+dhe]

@speccery thank you for your discussions on the zoom meeting regarding your inventions!

 

As it happens, later that night I was reading the book 'The Amiga Years'. One of the characters that was discussed was a former digital logic designer, who was hired in to Commodores chip division. An example was given 'a counter' which is made up of adders.. And the need to think differently between implementing logic with TTL, vs creating chips. So, my hat is off to you for being able to essentially create chips and interface with the TTL side of the TI!

[speccery]

4 hours ago, dhe said:

@speccery thank you for your discussions on the zoom meeting regarding your inventions!

 

As it happens, later that night I was reading the book 'The Amiga Years'. One of the characters that was discussed was a former digital logic designer, who was hired in to Commodores chip division. An example was given 'a counter' which is made up of adders.. And the need to think differently between implementing logic with TTL, vs creating chips. So, my hat is off to you for being able to essentially create chips and interface with the TTL side of the TI!

Thanks @dhe for the comments! It was nice to have the opportunity to discuss with you, I don't recall us discussing before in person. I enjoyed the discussion. Good call overall  

 

The tools that are today available for circuit design are just amazing, things which used to be very hard can nowadays be achieved so much easier than in the past. With hardware description languages you can describe something like counter with ease. For example from my icy99 FPGA repository you can find my implementation of the TMS9901 chip.

It contains a couple of counters, below is the Verilog code handling a 14-bit counter called "decrementer" and an 8-bit counter "clk_divider". Thanks to synthesis tools, this stuff is converted into logic living inside a FPGA chip. It's not really different from a programming language like C. But the key difference is that everything occurs in parallel, and one has to keep in mind this is a description of a hardware circuit, not software running on a processor. That in turn sort of means that one needs to be able to construct TTL equivalent circuits in one's mind, to understand what a given statement might mean in terms of hardware resource usage.

reg [13:0] decrementer;      // 14 bit decrementer value
reg [7:0]  clk_divider = 8'd0;  

// stuff omitted...

always @(posedge clk)
begin
    if (!n_reset) begin
		// stuff omitted...
    end else begin
        clk_divider <= clk_divider - 8'd1;
		// stuff omitted...
        if (clk_divider == 8'd0) begin
            if (decrementer == 14'd0) begin
                decrementer = cru9901_clock[14:1];
                timer_int_pending <= 1'b1;
                disconnect_int3 <= 1'b1;
            end else if (cru9901_clock[14:1] != 14'd0) begin
                decrementer = decrementer - 14'd1;
            end
        end 
        if (!timer_mode) begin
            dec_read <= decrementer;    // The read register updated when not in timer access mode
        end
    end
end

Anyway, if you look at the code, the two counters clk_divider and decrementer both count down. When working with this stuff, the synthesis tools take care of the hard part of converting a simple decrementing statement like "clk_divider <= clk_divider - 8'd1;" into a description of the logic. So I don't need to think about adders   unless I really want to.

 

The StrangeCart is different of course, since it's emulating hardware in actual software running on the onboard processor cores.

 

[Tuxon86]

Is there any plan to bring this to market, or is it also a victim of the component shortage?

[speccery]

On 11/21/2022 at 3:44 PM, Tuxon86 said:

Is there any plan to bring this to market, or is it also a victim of the component shortage?

It is available in small quantities, as I assemble them manually... I think I still have a few ready to go and parts for more.

[speccery]

In this new discussion thread there's the question on how to load extended basic programs to a real TI today, if you just have a FIAD file. If someone only has a console and no other expansions, the StrangeCart can do this for normal TI Basic programs, since the serial port connection over USB supports XMODEM transfers and I have implemented the SCD1 disk. These transfers are not super easy, but not difficult either, you basically just need to issue a few commands over a terminal connection with a terminal supporting XMODEM.

 

This feature is possible since TI Basic supports GROM based DSRs. My understanding is that Extended Basic does not search for DSR there but rather in the memory space >4000...>5FFF. So if I wanted to enable similar disk access from Extended Basic, I would need to modify extended Basic itself to be aware of the StrangeCart and use its services for SCD1. Any comments, is my understanding correct?

[Tursi]

XB can use GROM DSRs.. anything that can access CS1 does so.

 

[speccery]

1 hour ago, Tursi said:

XB can use GROM DSRs.. anything that can access CS1 does so.

 

Really? Thanks for the information, that's great! In that case I should be able to just copy-paste my existing code into a GROM slot above extended basic. It appears normal extended basic has a 32K GROM, so I could just use the topmost 8K GROM slot at >E000 in GROM space and I wouldn't have to change any of the existing code of extended basic  

[RXB]

2 hours ago, speccery said:

Really? Thanks for the information, that's great! In that case I should be able to just copy-paste my existing code into a GROM slot above extended basic. It appears normal extended basic has a 32K GROM, so I could just use the topmost 8K GROM slot at >E000 in GROM space and I wouldn't have to change any of the existing code of extended basic  

All the updated new XB versions including the first GRAMKRACKER Extended Basic use 8K GROMs, only Original XB used the 6K GROMs.

Thus RXB, SXB, XB 2.7, XB 2.8, and others all would be a better choice. 

(After all 8K more does not cost alot out of 16Meg.)

[speccery]

18 hours ago, RXB said:

All the updated new XB versions including the first GRAMKRACKER Extended Basic use 8K GROMs, only Original XB used the 6K GROMs.

Thus RXB, SXB, XB 2.7, XB 2.8, and others all would be a better choice. 

(After all 8K more does not cost alot out of 16Meg.)

I'm not sure if I understand the implication here to what I am planning to do.

With regular extended basic and system GROMs, the first seven 8k GROM slots from >0000 to >DFFF would be already occupied, leaving the last slot at >E000 free. That's irrespective of whether the occupied GROM slots use 6k GROMs or 8K equivalents, since to my understanding the legacy console software is looking for GROM headers at 8K intervals. The easiest thing for me would be to just have a single GROM only for the DSR support (6k or 8k doesn't matter, I only need probably 1k or something like that), not having to modify any of the existing GROM headers or mix my code with existing code. In order to fit this DSR GROM image in the GROM memory space when extended basic is loaded, it would have to reside at >E000, since that's the only available slot in the 64K GROM base 0 (read address >9800 in the CPU's memory map).

 

With RXB and other extensions I believe that not only are 8K GROMs used, but also they have 5 GROMs instead of 4 in the legacy extended basic. Which means that without decoding the so-called GROM bases, the 64K GROM memory map is full, and there is no space left to put my DSR without merging it with other code in a given cartridge.

 

Further, to my understanding neither the extended basic cartridge nor the console GROMs support the multiple GROM bases in the sense that they don't decode fully the lower address bits, but rather they occupy all of the 16 bases. Thus with a standard extended basic cartridge, the first 56K of GROM space behaves the same way in all of the 16 bases. Having said that, with the StrangeCart I could support the different GROM bases easily, so I could force extended Basic or RXB or whatever to only appear in GROM base 0 (at >9800). In that case I could put my DSR for example to GROM base 1 (read address >9804) at GROM address >6000, and there would be no conflicting overlap. This should work if all the software uses properly the GROM base addresses and is able to remember and distinguish between GROMs in the standard base and base 1.

[RXB]

6 hours ago, speccery said:

I'm not sure if I understand the implication here to what I am planning to do.

With regular extended basic and system GROMs, the first seven 8k GROM slots from >0000 to >DFFF would be already occupied, leaving the last slot at >E000 free. That's irrespective of whether the occupied GROM slots use 6k GROMs or 8K equivalents, since to my understanding the legacy console software is looking for GROM headers at 8K intervals. The easiest thing for me would be to just have a single GROM only for the DSR support (6k or 8k doesn't matter, I only need probably 1k or something like that), not having to modify any of the existing GROM headers or mix my code with existing code. In order to fit this DSR GROM image in the GROM memory space when extended basic is loaded, it would have to reside at >E000, since that's the only available slot in the 64K GROM base 0 (read address >9800 in the CPU's memory map).

 

With RXB and other extensions I believe that not only are 8K GROMs used, but also they have 5 GROMs instead of 4 in the legacy extended basic. Which means that without decoding the so-called GROM bases, the 64K GROM memory map is full, and there is no space left to put my DSR without merging it with other code in a given cartridge.

 

Further, to my understanding neither the extended basic cartridge nor the console GROMs support the multiple GROM bases in the sense that they don't decode fully the lower address bits, but rather they occupy all of the 16 bases. Thus with a standard extended basic cartridge, the first 56K of GROM space behaves the same way in all of the 16 bases. Having said that, with the StrangeCart I could support the different GROM bases easily, so I could force extended Basic or RXB or whatever to only appear in GROM base 0 (at >9800). In that case I could put my DSR for example to GROM base 1 (read address >9804) at GROM address >6000, and there would be no conflicting overlap. This should work if all the software uses properly the GROM base addresses and is able to remember and distinguish between GROMs in the standard base and base 1.

Only REA (Rich Editor Assembly resides at GROM >E000), so no you using that GROM would only disable EA support and have no effect on RXB XB programming at all.

 

I actually did release a version of RXB that supported 3 GROM bases, >9800, >9802 and >9804, but never really took off as it would not work outside of Classic99.

You could swap carts with a single command and back so this cart used 88K of GROM space in 3 GROM bases.

i.e. FinalGROM had not been created yet.

 

Also GROM base >9800 is not only base you could put any cart, so putting your base at >9804 would be fine and good.

There is built into TI99/4A support for 640K of GROMs so not like there is a lack of space and we almost never use more than 3 bases in total leaving 520K unused!

[+Ksarul]

On 11/29/2022 at 1:01 PM, RXB said:

I actually did release a version of RXB that supported 3 GROM bases, >9800, >9802 and >9804, but never really took off as it would not work outside of Classic99.

You could swap carts with a single command and back so this cart used 88K of GROM space in 3 GROM bases.

 

Rich, this variant would also work fine in an UberGROM cartridge on real iron--and based on the way the Strange Cart is being implemented, it looks like it would probably work there too. You might want to provide him the code to see if it works there. . .and I could always try to build an UberGROM image for it too.

[RXB]

4 hours ago, Ksarul said:

Rich, this variant would also work fine in an UberGROM cartridge on real iron--and based on the way the Strange Cart is being implemented, it looks like it would probably work there too. You might want to provide him the code to see if it works there. . .and I could always try to build an UberGROM image for it too.

In ATARIAGE search just type:

SWGR

and you will see all my posts on it.

 

I did not upload the source code for it unfortunately.

Did not label the code so somewhere in my RXB 2012 backup versions is the code I wrote for this.

Would take some digging thru my backups to find it.

Quick 10 minutes have not found anything so may not have kept the code.

 

I do have a printout on how it works, and it is documents in all GPL docs.

REA2012.zip

[speccery]

Didn't realise its been this long since an update here... Sorry, I'll try pick up speed with this thread as well. Even if I've been busy with RL it shouldn't be hard to improve from a 3 month interval...

 

Anyway I started to do minimal order fulfilment by assembling two new StrangeCarts. This is the newest PCB iteration - a design I did 6 months ago but only now am assembling. It's the same as the previous one, except the edge connector is about 1mm deeper.

 

For assembly I'm testing the approach I've been using with good success with the GROMmy boards: hot plate with low temperature solder paste. I don't have a stencil and as you can see the hot plate is so small that it's only baking half a board at a time. But the nice thing is that it follows the temperature profile. Also, even without the stencil and manually placing components, the build process is faster than with individual soldering. During working week I anyway don't have enough time in one evening (with other unrelated activities) to assemble a board fully, so one half at a time should work well. I will reflow the chips with a soldering iron afterwards, without a stencil the TQFP package is not going to solder properly...

 

[cobracon]

Do you have a website for this?

[PeteE]

16 minutes ago, cobracon said:

Do you have a website for this?

https://github.com/Speccery/StrangeCart-Doc

[speccery]

11 hours ago, PeteE said:

https://github.com/Speccery/StrangeCart-Doc

Thanks @PeteE for the help here. I will add that link to the first message of the thread.

[speccery]

I've been building a couple of StrangeCarts and I also have interest from the community for some more, so I wanted to make the build process slightly faster by automating testing. I have sketched a test sequence I take every board through before sending them over, but I realised I can still improve the coverage and make the testing job easier for me.

 

The most common problems I have encountered are that the microcontroller is not properly soldered. I do it by hand, and I try to do it very carefully, but mistakes still sometimes happens. There are two main categories; shorting two pins next to each other (the distance between pins is 0.25mm, even a tiny bit of solder can bridge them) or that there is too little solder somewhere, and a pin I thought is connected actually is not. The latter is actually the main issue, I'm pretty good at spotting solder bridges and double and triple check for this before applying power for the first time.

 

To help with this, I now added a test mode to the firmware ("pintest"). It's a simple algorithm, which configures almost all of I/O pins into GPIO mode and sets the as inputs, with internal pull up resistors enabled. As a result, all I/O pins should read as ones. Then I run a sequence, where I set one pin at as an output, and drive it briefly low. When done, I check that it actually went low, and also that no other pins went low (indicating a short).

 

This simple pintest is very effective, I use it as follows:

• I first check for shorts. With the board unplugged (only USB connected) I run the pintest once, and if all is well nothing is shorted and any input doesn't go suddenly low when another pin is configured as output driven low. This tells me that there are no shorts, but it doesn't tell me if pins are properly soldered.
• Once the above test succeeds, I plug in the board to the TI and run Parsec from the StrangeCart. That tests all address and data lines and most control lines.
• I then unplug the board from the cartridge slot to test the remaining lines, meanly used for optional extensions. To test these I apply manually a wire between two pins, just holding it with my hands while running the test. What should happen when I run the pin test is that I get two errors, for both of the pins connected with the extra wire there should be another pin which follows it, due to the wire. If I don't get an error, one of the pins is not soldered properly. If I get two errors, it's good, and I move the wire between two other pins and run the test again. This way I can very quickly cover all the pins not used when running Parsec. There are 11 extension pins like this.

Edited February 26, 2023 by speccery

[Appeelicious]

This is pretty interesting to read about your method. I'm going yo read up on the strange cart out of curiosity and peek out how it differs from other multicarts. I suspect it does something unique