Jump to content

Recommended Posts

Quick update: I'm currently building a batch of 6 boards for distribution. The 6 is just an arbitrary number - building fewer would mean spending more time finding components and their locations on the board, building more in one go would mean that a pass of adding some components to all boards being constructed could take too much time to enable me to build on a piece meal fashion, time permitting. I will see how this goes. Just under half components now soldered, I am leaving the most time consuming (and expensive) parts last.

 

I also worked on the Basic a bit more a few days ago, adding support for read-data-restore. Haven't yet tested those on the real hardware, but the TI Basic game "escape" now runs on my Mac (not supporting user defined characters etc. makes it hard to see if it's doing the right thing). When I have a moment I'll test on the hardware.

  • Like 8

Share this post


Link to post
Share on other sites

really awesome results! you can be proud!

just to get it right:
- this interpreter is done from scratch by you

- this interpreter aims to do TI Basic, not XB

- this interpreter was not done with the source code or specifications of the TI-99 Basic interpreter and is therefore using the scratchpad different.

 

  • Like 3

Share this post


Link to post
Share on other sites
11 hours ago, kl99 said:

really awesome results! you can be proud!

Thank you @kl99 it has been a fun project. It took quite a while to build the foundation firmware, but not that it starts to in place writing additional things like the BASIC interpreter things move much faster and smoothly.

11 hours ago, kl99 said:

- this interpreter is done from scratch by you

Yes, 100% my code in C++. I have used C++ features sparingly, so it's quite C like code.

11 hours ago, kl99 said:

- this interpreter aims to do TI Basic, not XB

We need to walk before we can run. I intend to expand on this to also cover XB (i.e. create a derived C++ class adding XB), but that will take a while to do, even TI BASIC is not completely done yet. I anticipate that much of the harder work (string management and expression evaluation) is already there for both XB and normal BASIC, so adding things is relatively easy.

11 hours ago, kl99 said:

- this interpreter was not done with the source code or specifications of the TI-99 Basic interpreter and is therefore using the scratchpad different.

It is actually not using scratchpad much at all, just the floating point temporary space. It is not altering the state of TI BASIC. In fact you can have a normal TI BASIC program doing "CALL RUN(0)" to run another BASIC program stored into the RAM of the StrangeCart.

  • Like 3

Share this post


Link to post
Share on other sites
15 hours ago, speccery said:

First video of the BASIC interpreted I am working on: 

 

 

This is an interesting cart that could also be used for some fancy things. For example, having an emulator (maybe a Spectrum) running on the cart and  using the TI for I/O (video, keyboard, joysticks). Is it techical feasible?

 

  • Like 5

Share this post


Link to post
Share on other sites
1 hour ago, dhe said:

So much gets done, so few parts. What's the bill of materials look like?

Yeah, so much is done in software. I attempted to keep the hardware design minimal. Even then, now that I assembled the first "proto production" batch, there are 48 components in total + the PCB itself. The most expensive and significant parts are the microcontroller and flash chip. Then there's a fair amount of usual suspects like voltage regulator, crystal, buttons, LEDs, a couple diodes, micro USB connector pin headers, and finally a whole bunch of passives. Quite a bit of assembly work overall. Below is a picture of one of these new boards, still with the bloody typo in the name. There are some provisions for additional components, but not needed at the end of the day.

IMG_4918.thumb.jpg.046cacbf1617429133b8381b514e8e6d.jpg

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, tmop69 said:

 

This is an interesting cart that could also be used for some fancy things. For example, having an emulator (maybe a Spectrum) running on the cart and  using the TI for I/O (video, keyboard, joysticks). Is it techical feasible?

 

It is mostly feasible. The bottleneck, if there is one, would be TMS9900 handling the I/O. Like you probably already know, the Spectrum has a very simple architecture. But compared to the TI, it has much faster access to video memory, since the video memory appears in the main memory address space. I don't think emulating a Z80 is much of a problem.

Share this post


Link to post
Share on other sites
2 hours ago, tmop69 said:

 

This is an interesting cart that could also be used for some fancy things. For example, having an emulator (maybe a Spectrum) running on the cart and  using the TI for I/O (video, keyboard, joysticks). Is it techical feasible?

 

I was thinking CP/M or Geneve-a-like in-a-cart, with the limitations of the 9918A or F18A enhancements.

  • Like 5

Share this post


Link to post
Share on other sites
2 hours ago, tmop69 said:

 

This is an interesting cart that could also be used for some fancy things. For example, having an emulator (maybe a Spectrum) running on the cart and  using the TI for I/O (video, keyboard, joysticks). Is it techical feasible?

 

It would actually be a very good platform for an MSX (1) emulator. Everything except for the CPU is a really good match for the TI

 

*edit* or Colecovision or SG-1000

Edited by TheMole
  • Like 5

Share this post


Link to post
Share on other sites

I wouldn't be interested in emulating other computers, I don't see the point... I am a 99er :) the F18A is already borderline interest for me 😛 
 

I find interesting the possibility to have a Geneve on a cart or CP/M Z80 as suggested @OLD CS1, or in other resources that can be useful to make better and smoothly the use of existing software/developing strictly for the TI99.

Perhaps the TI-99/2 or TI-99/8 on a cart might also be of interest.

just my 2c.

  • Like 2

Share this post


Link to post
Share on other sites
7 hours ago, TheMole said:

It would actually be a very good platform for an MSX (1) emulator. Everything except for the CPU is a really good match for the TI

 

*edit* or Colecovision or SG-1000

As far as I understand all VDP access and I/O would have to go through the TMS9900, so the StrangeCart would have to continuously generate a program in cartridge space that the TMS9900 executed, which means we would still be limited by the TI's bandwidth to the VDP, which would be further limited by the time it would have to spend on I/O. It sounds easier to write an emulator for the F18A, because that at least can access the video RAM directly, but for the F18A I guess the limiting factor would be the lack of RAM.  

  • Like 1

Share this post


Link to post
Share on other sites

You would, but, it would probably be sufficient for all but the hardest-pushing software. You'd just be redirecting the Z80 IN and OUT instructions to the TI, it wouldn't need to worry about anything else. It would be slower than the native machine's access, but since they have to slow down their VDP accesses to avoid overrun anyway, it'd be pretty close.

 

(Edit: couldn't stop thinking about it ;) )

 

Inputs, you'd have to wait for response anyway, there's no choice there. But output to the VDP I'd do asynchronously. That is, I'd let the emulation continue while the board dealt with sending the byte to the TI. Only if a second byte came along before the first one was done would I hold the emulation. That way the emulated program can get on with its NOPs while the extra processing happens.

 

For the sound chip output I would do that one in real time, at least on the ColecoVision, since their chip holds the CPU the same as ours does. But I think the MSX's AY does not, so I'd do the same sort of asynchronous write to avoid slowing down the emulated program too much. Most (not all) of the AY's range can be played on the TI chip, so simple translation will go a long way. (Envelopes are lost though...)

 

I wanted to do an Apple 2 emulation myself ;)

 

Edited by Tursi
  • Like 6

Share this post


Link to post
Share on other sites

As far as CP/M goes, while not the best model, the Commodore 128's CP/M is divided between two CPUs: the Z80 to run the OS and software, and the 8502 for BIOS calls.  In that same style, the StrangeCart could be running the CP/M system and issue requests and respond to the TI side for I/O, including screen.

 

A TI implementation of CP/M in this manner would be more crippled than the C128, on which the Z80A has direct access to the VDC and VIC-II for video, and supposedly the 6526/8520 CIAs for scanning the keyboard*.   The StrangeCart cannot have direct access to system devices, the 9918A, 9919, 9901, &c.  That would all have to be handled by a running TI BIOS companion.  Shared memory space in the cartridge port region would be useful here to move data between the TI and CP/M.

 

* I have some confusion on this point.  It appears the Z80 can access these chips directly, but calls go through the 8502 BIOS.  Not completely certain anymore if the MMU mediates Z80 access to I/O space or not.  Notwithstanding, the TI points I made stand.

 

  • Like 2

Share this post


Link to post
Share on other sites
17 hours ago, Asmusr said:

As far as I understand all VDP access and I/O would have to go through the TMS9900, so the StrangeCart would have to continuously generate a program in cartridge space that the TMS9900 executed, which means we would still be limited by the TI's bandwidth to the VDP, which would be further limited by the time it would have to spend on I/O. It sounds easier to write an emulator for the F18A, because that at least can access the video RAM directly, but for the F18A I guess the limiting factor would be the lack of RAM.  

Well, if you have a high quality C++ compiler for it... I guess GCC could be made to target it.

 

The benefit of using the ARM core is that you have high quality toolchains, 32-bit data path throughout and you have the flat 32-bit address space, and hardware floating point.

 

I have been thinking about a direct SPI bus from the strangecart to a FPGA version of the VDP. I may try a proof of concept with my own VDP design in the icy99. It's not as cool as the F18A, but easy for me to work with. I have never connected it directly in place of the VDP like the F18A does, but that should not be a problem. Even at a moderate clock of 8MHz it would achieve one megabyte/s block transfers which would be many times faster than what is currently going on. I am currently running the SPI bus at 48MHz when communicating with the onboard serial flash chip

Edited by speccery
  • Like 2

Share this post


Link to post
Share on other sites
14 hours ago, OLD CS1 said:

As far as CP/M goes, while not the best model, the Commodore 128's CP/M is divided between two CPUs: the Z80 to run the OS and software, and the 8502 for BIOS calls.  In that same style, the StrangeCart could be running the CP/M system and issue requests and respond to the TI side for I/O, including screen.

 

A TI implementation of CP/M in this manner would be more crippled than the C128, on which the Z80A has direct access to the VDC and VIC-II for video, and supposedly the 6526/8520 CIAs for scanning the keyboard*.   The StrangeCart cannot have direct access to system devices, the 9918A, 9919, 9901, &c.  That would all have to be handled by a running TI BIOS companion.  Shared memory space in the cartridge port region would be useful here to move data between the TI and CP/M.

 

* I have some confusion on this point.  It appears the Z80 can access these chips directly, but calls go through the 8502 BIOS.  Not completely certain anymore if the MMU mediates Z80 access to I/O space or not.  Notwithstanding, the TI points I made stand.

 

On the Commodore 128 you have an either or situation: only one of the CPUs can run at a time, they share the bus and can't operate concurrently. My understanding (which may be wrong) is that the Z80 can access all the peripherals. In fact I do know that when the commodore 128 boots, it's the Z80 which boots at reset and then yields to the 8502 after doing a bunch of stuff. 

 

I've been thinking about CP/M too. Effectively the TI would become a close coupled terminal to a CP/M system. The performance would probably be good.

Share this post


Link to post
Share on other sites
1 minute ago, speccery said:

"... high quality toolchains and you have the flat 32-bit address space, and hardware floating point."

You are reminding me of a Chief engineer that I worked for many years ago.  He lived through the war and managed to evade the advancing Eastern troops and made it to the western side as a 15 year old.

If we complained that we needed better tools he would say "Anybody can fix it with tools! After the war all I had was toe nail clippers and my grandmother's nail file" :)

 

  • Haha 2

Share this post


Link to post
Share on other sites
50 minutes ago, speccery said:

On the Commodore 128 you have an either or situation: only one of the CPUs can run at a time, they share the bus and can't operate concurrently. My understanding (which may be wrong) is that the Z80 can access all the peripherals. In fact I do know that when the commodore 128 boots, it's the Z80 which boots at reset and then yields to the 8502 after doing a bunch of stuff. 

 

I've been thinking about CP/M too. Effectively the TI would become a close coupled terminal to a CP/M system. The performance would probably be good.

The C128 is an amazing kludge of a machine.  It is said to be a three-mode computer, but I count five discrete configurations, amazingly arbitrated by the MMU:

  1. Boot (Z80)
  2. CP/M (Z80 and 8502)
  3. C128 (8502)
  4. C64 (8502)
  5. 64GS (8502)

Without falling too far down the rabbit hole here, there is plenty of documentation out there which describes the technical details of CP/M mode on the Commodore 128, and I found this thread which straddles the line of technical and non-technical.

 

The way I envision CP/M on a StrangeCart TI is the >6000->7FFF cartridge space split between ROM and RAM (banked if necessary) with the ROM presenting a CP/M 3.1 menu option which fires up a Z80 (or 8080) core running on the StrangeCart, and a BIOS service system on the TI.  The TI does all of its native DSR set ups and presents that to the StrangeCart the same way it would its own operating environment.  Similar to how the CBM drives detect drive formats, the TI would need to figure out when an inserted floppy is using native TI format or a CP/M format, or the native TI format could be bypassed and detection of one of the myriad CP/M formats could be assumed.

 

Using the C128 paradigm, the RAM at the top of cartridge space is set up as "mailboxes" for BIOS calls and returns, including data caches for file loads, saves, active file buffers, keyboard buffer, joystick input, RS232 and PIO, screen, &c.  I suspect the TI CP/M BIOS could run in 4k of cartridge space, but likely would benefit bigly by running in 32k.

 

In terms of mass storage, the TI CP/M BIOS would have simple configurations which tell the system where CP/M is located on a TI native-formatted hard drive or equivalent (i.e. SCS1.CPM3) or the entire device could be dedicated to CP/M (SCS3).

 

https://obsolescence.wixsite.com/obsolescence/cpm-internals

 

That is enough system analysis for now.  I need to get on to real work.

 

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, OLD CS1 said:

The way I envision CP/M on a StrangeCart TI is the >6000->7FFF cartridge space split between ROM and RAM (banked if necessary) with the ROM presenting a CP/M 3.1 menu option which fires up a Z80 (or 8080) core running on the StrangeCart, and a BIOS service system on the TI.  The TI does all of its native DSR set ups and presents that to the StrangeCart the same way it would its own operating environment.  Similar to how the CBM drives detect drive formats, the TI would need to figure out when an inserted floppy is using native TI format or a CP/M format, or the native TI format could be bypassed and detection of one of the myriad CP/M formats could be assumed.

 

Using the C128 paradigm, the RAM at the top of cartridge space is set up as "mailboxes" for BIOS calls and returns, including data caches for file loads, saves, active file buffers, keyboard buffer, joystick input, RS232 and PIO, screen, &c.  I suspect the TI CP/M BIOS could run in 4k of cartridge space, but likely would benefit bigly by running in 32k.

 

In terms of mass storage, the TI CP/M BIOS would have simple configurations which tell the system where CP/M is located on a TI native-formatted hard drive or equivalent (i.e. SCS1.CPM3) or the entire device could be dedicated to CP/M (SCS3).

 

That is enough system analysis for now.  I need to get on to real work.

Thanks for sharing your thoughts.

What you wrote about how CP/M would work is more or less how the StrangeCart already operates when it's running the Basic interpreter: there is 4K ROM, 4K RAM and some GROM. The 4K RAM is used as a shared communication mailbox.

 

There is a reason why the StrangeCart has the 128Mbit Flash chip - not only for storing cartridge images, but it could also locally host a filesystem for CP/M for instance. It's not a huge storage medium, but certainly larger than the first hard disks were... And plenty for something like CP/M.

Of course it would also be good to use TI DSRs to support other storage mediums too.

 

Good luck with the real work ;)

Share this post


Link to post
Share on other sites
58 minutes ago, speccery said:

There is a reason why the StrangeCart has the 128Mbit Flash chip - not only for storing cartridge images, but it could also locally host a filesystem for CP/M for instance. It's not a huge storage medium, but certainly larger than the first hard disks were... And plenty for something like CP/M.

IIRC, the REU (RAM Expansion Unit) RAM disk sits at M: on the C128 CP/M system.  The internal file system of the StrangeCart could assume that position.  Very cool.

 

1 hour ago, speccery said:

Good luck with the real work ;)

Thanks.  Without going on a rant, Microsoft is not making my work any easier and is usurping at lot of what I do and my customers, but I have a cunning plan.  And BBQ for lunch.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, OLD CS1 said:

IIRC, the REU (RAM Expansion Unit) RAM disk sits at M: on the C128 CP/M system.  The internal file system of the StrangeCart could assume that position.  Very cool.

 

Thanks.  Without going on a rant, Microsoft is not making my work any easier and is usurping at lot of what I do and my customers, but I have a cunning plan.  And BBQ for lunch.

Sounds like a good lunch then - and plan :) . Bon apetit!

Share this post


Link to post
Share on other sites
3 hours ago, speccery said:

Well, if you have a high quality C++ compiler for it... I guess GCC could be made to target it.

You can write emulation in C, you know. ;) Or any other language.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...