speccery

October 22, 2022

23 hours ago, RXB said:

RXB has GPL command CALL MOVE that moves any type of memory to any type of memory of any size, including GROM/GRAM

This command could be included into TI Basic.

That would be really great! I need to look up the RXB documentation to see the syntax. Also would be nice to add PEEK/POKE/etc. to TI Basic.

October 22, 2022

20 hours ago, ti99iuc said:

I had two RS232 connected but still missing PCode and the Video Controller ones are very rare to find, also if I have to say that all this stuff I rare to find in Italy. Better easily to find this in the USA.

Impressive display there!

What is the Video Controller?

October 21, 2022

1 hour ago, Tursi said:

I'm really sorry about that! I just checked in Classic99 and it doesn't work there either... so I guess my memory was faulty on this one.

The patch to make it actually work is really cool, nice work on that!

And yeah, put those modern processors to work serving a REAL machine

No worries, has happened to me many a time. As a side product the simple test circuit is nice as it allows tuning of the code and seeing how much time it takes to serve requests.

The mini memory cart is really cool, I have modified it a lot to work as a gateway to StrangeCart basic. But now I see there are many ways it can be improved in its original form too. Among very simple modifications would be the addition of better documentation. The help screen is very nice, but I always find myself wondering how the CRU addresses should be entered, I have to look at the source or experiment every time.

October 21, 2022

On 10/11/2022 at 7:17 AM, Tursi said:

EasyBug does support writing to GROM, it's how I tested the UberGROM

Console GROMS work fine from the cartridge port.

Well I was really scratching my head why the heck my second version board did not work properly with writes. The reason: easy bug in mini memory DOES NOT support writing to GROM. Not at least the version I have compiled myself as part of the Strangecart image. I built a little involved test circuit:

There is a 74HC138 logic chip I attached for debug purposes to trigger my scope, in a configuration where output Y0 of that chip goes low when a GROM write occurs (i.e. /GCS, MO and R/W are all low simultaneously). I tried to write to GROM with Easy bug, no luck. When I looked at the source code, it explicitly was not writing to GROM. I added a bit of code to change that, so now it can write to GROM. I got the source code from Thierry's tech pages. I edited the source a long time ago so that I can compile it with xdt99 toolchain (xga99.py). Below is the edited version with support for writing, starting from the label G_EP_WR_GRAM. Without this addition, when pressing enter with the G command it would just jump to G@G73E0.

*                             write to CRU
G7437  CEQ   >43,V@>02C3      ------------ was command <C>?
***       BR    G@G73E0          no: next address (can't write to GRAM)
       BR    G@G_EP_WR_GRAM
       DST   @>839A,@>83B0    address will be CRU address
       ST    >01,@>83B2       1 bit operation
       ST    >99,@>83B3       value is in >8399
       DSRL  >0001,@>83B0     divide CRU by 2 (GPL multiplies it again)
       I/O   >03,@>83B0       CRU output
       B     G@G73E0          next address

* Erik: added ability to write to GRAM
G_EP_WR_GRAM
       CEQ   >47,V@>02C3    --- was command <G>?
       BR    G@G73E0        no
       MOVE  >0001,@>8399,G@>0000(@>9A)   -- Write to GRAM (Does this work?)
       B     G@G73E0          next address

With the added code I immediately got triggers for my scope when writing to GROM.

My development TI is pretty full of ARM processors these days, one in TI-GROMmy, one in StrangeCart (actually two cores there), one in the ET-PEB board on the side expansion port, one in the Nucleo board I've plugged in to the keyboard port....

October 16, 2022

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.

October 12, 2022

On 10/10/2022 at 9:00 PM, Duewester said:

@speccery I'm interested in your grom replacement setup. How can I get one for testing or otherwise contribute to your research and development.

Thanks for the interest! The easiest way for now is me to send you a tested one. I need to build a few these for others too. Will send you a PM when I have some ready for shipment. I just got a whole bunch of PCBs from manufacturing and a load of components for this and other projects, the only missing piece is time....

October 12, 2022

@Shift838 just today received my order #12, thanks a lot! It took a while through the customs and everything and the packaging had clearly received a few bumps en route, but all the content seem to be in good order. Now I only need to find the time to put all of this together, buy a suitable case and power supply

October 10, 2022

A quick update: I have added to the firmware the ability to write to flash permanently the changes written first to RAM. I haven't been fully able to test this since I'd need a GROM editor / monitor program for that purpose. I think Easybug, provided in Mini Memory module, supports GROM reading but not sure if it supports writing. Haven't had time to try that out yet, as I just realised it might.

Also got today a batch of boards from PCBWAY, new version of TI-GROMmy PCB and two other brand new designs...

October 6, 2022

5 hours ago, matthew180 said:

Also, if you are going to remove the SRAM, don't stop there, make a board for both the SRAM and ROMs, and make it such that the ROMs are really SRAM as well, and are loaded from something at power-on, such that they can be replaced with new code. This would allow for truly new capability of the 99/4A. It would be really cool if such a device could connect to a PC via USB or network, and allow real-time reading/writing of the RAM. This would make writing and debugging software for the 99/4A really awesome.

Two comments, a small and a big one

My FPGA implementations of the entire TI-99/4A support modifying RAM/ROM contents on the fly over USB. That's a very convenient feature to have, and it's how I debugged those designs. It could be taken much further of course, and integrated with a PC side IDE...
I've been thinking about designing this type of 32K 16-bit wide memory board. Due to the hassle of installing such a thing, I've almost arrived at the conclusion that it would be easier and more accessible to "just" do a whole new motherboard. For video functionality just have a normal socket for F18A, CPU and TMS9901 would have to be extracted from an actual TI or sourced otherwise, GROMs would be come from my GROMmy board, sound chip seems to be socketed at least on the TI I have open here, all glue logic would go into a CPLD or small FPGA. Such a board could be less than half the size of the normal motherboard, and run from a 5V power supply. If an actual TMS9900 is used as the CPU, there would be the need for a small switching power supply to generate the -5V and other potentially required voltages. I'm not very interested in the discussion when a TI is no longer a TI, but in my opinion if an original CPU would be used it would be pretty close. Doing a prototype with TMS9995 would be easier, and actually would be roughly identical to the Tomy Tutor.

October 6, 2022

16 hours ago, Switch1995 said:

Each range is accessing the same memory, however it is pretty much universally accepted that the scratch pad should be addressed from >8300 to >83FF. Something I've always wanted to do is add real memory to each of those address ranges and give the 99/4A 1K of real 16-bit scratch pad RAM! But that's another day, another project.

I have in my other projects (FPGA implementations of the entire TI-99/4A) supported 1K scratchpad, and that's something which works well. I have actually also tested filling some of the other gaps in the I/O area with RAM too.

October 2, 2022

I got the TI-GROMmy working without the patch wire to ground. The nice thing with a very simple two sided PCB is that it is very easy to modify

I only did three changes:

Cut the trace going to pin 16 of the GROM socket. This is the Vss pin, effectively ground, which is at -0.7V level in the TI-99/4A.
Added an 1N4148 diode from the board's ground to pin 16, effectively lifting the ground level to 0V. According to my voltmeter the level is now at 35mV which is effectively zero. I don't trust my voltmeter too much, but this close enough to zero.
Added an extra wire to make the board flashable while in the TI using a FTDI dongle. In the past I used a jumper to select whether the board is in programming mode, but now I swapped a pin and altered the firmware accordingly.

Below pictures, it doesn't look too bad in my opinion. I will revise the PCB accordingly for the next spin of the board, but this mod is quick to make even for the existing PCBs.

Edit: forgot to mention that I also worked on the firmware to reduce it's size and to align the 24K GROM image on a flash sector boundary. The firmware does not yet support in-system flashing, but it's now just under 28K with 24K GROM data. The additions I am planning to make (primarily ability to reprogram the Flash while in the console) are minor, and should easily fit into 1K. So it should be possible to have an extra 3K of flash space free when all features are there

September 28, 2022

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.

September 28, 2022

9 hours ago, kl99 said:

Is it meant to be followed by a similar thing for "programmable"/writable ROM chips?

Thanks for your comments!

Actually the TI-GROMmy is writable from a hardware standpoint, I just need to enable this in the firmware as well. The way I am planning to do it is by reserving a bit of space, for example the last 16 bytes, from 5FF0 to 5FFF for special commands. By writing a magic signature there, the firmware would write the modified content (in SRAM at that time) to the Flash, while the device is inside of the TI.

With a similar mechanism the device could be put into an update mode, where the entire 24K could be updated. Probably the easiest way to do it would be to prepare a paged cartridge image, which you could run from FinalGROM or StrangeCart or something similar to do the update.

September 25, 2022

46 minutes ago, RXB said:

I put out a package of EA Cart TI Basic Assembly support built into GROM 2 and 3.

I uploaded it to Atari Age but can not find it?

Thanks - a quick question. the GROMmy handles GROMs 0,1 and 2, i.e. the system GROMs. Does your EA Cart require the additional GROM 3 as well? I may be able to hack something together to allow for that, but it would collide with cartridges inserted into the cartridge port.

September 25, 2022

I just wrote an update about my TI-GROMmy project. It supports the GROM writability as required by the MMXB.OBJ described in the first message of this thread.

By the way, if anyone has other similar pieces of code (modifying system GROMs) I would be very interested in testing that with TI-GROMmy.

September 25, 2022

An update to this project: I have the first useful firmware version now ready. It is very simple: it emulates the entire 24k of system GROM successfully, and also supports writes to this region, i.e. it acts as GRAM.

The GRAM functionality works as I contemplated here before: there is a 6K section of RAM which is divided into 256 byte pages. When a given memory location is written, say address >1234, that entire page is copied to RAM. Thus the data from >1200 to >12FF would be copied to RAM, and then within this page location >34 would be modified with the data written. Subsequent accesses to the GROM address range from >1200 to >12FF will both write to and read from RAM.

This GRAM functionality works as long as the total number of modified 256 byte pages fits into the 6K RAM. The pages do not need to be consecutive. For example, @senior_falcon's interesting project here at AtariAge works with TI GROMmy on the real iron. It only writes a few bytes to GRAM, to pages >50 (>5000..>50FF) and >36 (>3600..>36FF), which get copied to RAM and then modified.

September 25, 2022

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.

September 15, 2022

5 hours ago, Ksarul said:

Considering that I have been playing with some test boards that replicate the TIM (I can send you an assembled one if you like, @speccery, along with a few strips of the pins I use, as they are as thin as regular chip socket legs), it would definitely be interesting for me to test one of these using the SOB GROMs. Timing is good too, as I just got a small group (10) of V9938 pulls that supposedly came from working game cabinet boards that were being parted out.

That’s great, I will send you one and also very interested in the TIM. Where do you source the thin strips? I will send you a PM.

September 14, 2022

2 hours ago, RXB said:

Not enough space to do that, I modified Disk Manager to handle up to 9 disks or RAMDISKS and to do this would remove TI Basic from the GROMs.

I also put out a modified EA cart support installed into TI Basic that some people use but does not have disk access like Disk Manager.

How much space would you need?

September 14, 2022

4 hours ago, RickyDean said:

I bet the TIM SOB firmware would be usable on this too. I want 3. You know, I've never really considered it, but I bet it's possible to load the sob firmware to my GramKracker too.

I feel that I’m still learning with every new project about software I didn’t know about… what does TIM SOB do? Some kind of driver for 80 column mode?

September 14, 2022

I will need to put some finishing touches to the firmware (i.e. to support the writability) but that should not take long. Would someone be interested in testing these boards? Would be nice to collect feedback and improvement ideas.

I would not recommend putting this in at this stage if you only have one console to work with, but I guess most people discussing here have several (I think I have four, two of which I use for testing and hardware development). The legs of the TI-GROMmy are thicker than those of ordinary GROM chips, but for me this has not been a problem and they fit in snuggly into the sockets. I've just soldered in standard pin headers.

Please let me know if you're interested in testing.

September 13, 2022

Enter the TI-GROMmy, a modern replacement board for the system GROMs of a TI-99/4A.

I already posted about this project in Facebook a while ago, so many of you may already be aware of what I have been working on. I took a short break from StrangeCart development and created this small board, which can be used to replace the three internal GROM chips. I have had it in sort of working order for a week or so, but only yesterday or the day before ironed out the last bugs.

Here is the board in the flesh installed into my TI-99/4A. As you can see from the dimensions, it takes the space of two GROM chips. For my latest testing I removed the remaining GROM, so all three are being served by the TI-GROMmy.

This board can be used to replace the system GROM chips, therefore enabling:

- Fixing a TI with defective GROM chip(s)

- Run any of the TI operating system versions, at least as far as the GROMs are concerned. In the current firmware version the MCU has to be reprogrammed with the GROMs you want to use.

- Extend the system GROMs to 8k each, as the TI-GROMmy already serves the entire 8K instead of the regular 6K for each chip, enabling additions to the standard GPL code.

- Create your own improved version of the GROM code and run it on the real iron.

Not done yet, but I will also alter the firmware so that the GROMs become writable. The LPC824 microcontroller used here has 8K of SRAM, and my plan is to use 6K of that for RAM based override: I will modify the firmware so that I will split the 24K of system GROM space into 256 byte pages, thus having 96 pages in total. If a GROM write is done, the 256 byte page containing the target byte is entirely copied to SRAM, and the write is done into SRAM. From that point on the SRAM version of the 256 byte page will be used. This way one can non destructively write to various areas of the system GROM, as long as the total amount of changes is less than 6K, you will be able to go on developing.

Edit: 2022-09-25 the writing now works.

The board has a LED, it is lit whenever the TI-GROMmy is driving data to the bus. Thus whenever a read operation into the system GROM is in progress, the LED is lit. In practice it is constantly dimly lit when TI BASIC is running.

I have tested the board with an actual Mini memory cartridge, and they seem to happily coexist. I have also tested it with the StrangeCart, and they can also nicely coexist. I have to locate my stash of the cartridges to try with other boards , but with the limited testing so far this all seems to work.

I have several test boards I've built, the one in the picture above as a straight pin header for programming the MCU, while another board has a right angle header to make the height of the board lower. A simple FTDI USB dongle is all that's needed to program the MCU, the open source program lpc21isp does the job nicely.

Compared to all of my other boards I've done so far, this one is super simple and a fast build. There are only 11 components and some pin headers. The 3D model shows an additional zener diode D1 which does not need to be populated.

As can be seen in the picture, there is one wire going to ground. I chose to go this way, since the ground level Vss on the GROM socket is actually -0.7 volts, not zero volts, another TI weirdness. No real ground level is available on the socket. Using Vss level as ground would mean that the signal swing of the 3.3V microcontroller would only go to about 2.3V level above the real ground. While this level works, it is a bit low. Also the input pins of the microcontroller would be seeing signal levels higher than 5 volts, which might but their 5V tolerance to the test.

I will check if I could remove the need of the dangling ground wire and use the Vss level provided in the socket. I could add a simple forward biased diode from the board's own ground to Vss. A 1N4148 diode has typically a forward voltage drop of 0.6 volts. It would lift the board's ground relative to Vss to about -0.1V, which should be fine and would allow removing the bodge wire to ground.

September 13, 2022

@InfiniteTape Here is an example I took on my system. It's a working setup, working with my new TI-GROMmy board which replaces the GROMs. Not ideal for the pictures, but I think it serves as comparison material for you.

The yellow signal is GROM chip select. The cyan is channel 2 which is D0, pin 8 in the GROM socket. Same as in your measurements. The trigger is /CS going low. You can see that my GROM replacement is ready with the read operation in about 5 microseconds (2us per div) and driving the data bit high. I'm using a 5V tolerant microcontroller pin, but the MCU is running from a 3.3V power supply, so the high level is at around 3V.

I suppose the point in this picture is that if you look at what happens outside of the time period where /CS is low, the signals are all over the place, and the waveforms are similar to what you had.

Here is another capture. Since here D0 is high at about 4.5 volts, it must be a write cycle coming from the CPU as in my setup the MCU cannot drive a signal higher than 3.3 volts. This would be part of the address setup (which requires two cycles). Also here we see weird waveforms outside of the /CS low.

September 12, 2022

8 hours ago, InfiniteTape said:

Here is pin 11, which is the output D0 line that goes to the GROMs, sound chip, cartridge port, and expansion port. To me, this looks like what people in YouTube videos call a bus conflict, hence my suspicion of the logic chips leading to the GROMs. However, I haven't dug into one of my working consoles to compare.

I can look at this in the evening if I have time. I just designed a GROM replacement board which I got properly working yesterday, I will be opening its own thread for that when I have time . My TI is wide open at the moment due to that work, so easy to measure.

I'm not sure your picture displays a bus conflict. If the only activity which was done during the capture on the 8-bit bus is reading of GROMs, this could be ok - need to compare to a working TI though. The GROMs have weak drivers and they leave their outputs floating after the bus cycle is over (i.e. GROM CS goes back high). If nothing else is being read on the 8-bit bus then no device would actively be pushing the signal anywhere. It would be interesting to look at this if you would also include the GROM chip select signal on another channel.

My understanding is that a common failure point are the 4116 video RAM chips, if you have the F18A board you could plug that in to see if it fixes the issue as it incorporates its own VRAM.

I should mention that I did contribute a little to Noel's video by doing some comparison measurements for him. In his case one of the issues was a blown up ROM chip if I recall correctly.

August 17, 2022

Order 12. After a very long last it seems I will finally be getting my very own PE box! And I bet its' going to be a whole lot lighter to ship to Europe than an actual PEB... Of course I have zero expansion cards, but having this opens up new opportunities for FPGA designs...

Profiles

Forums

Blogs

Gallery

Events

Store

Posts posted by speccery