Erik's ET-PEB

[+adamantyr]

 

 

Thanks! The board does have a serial port, but it is not RS-232 voltage level compliant. An external level converter could be added. It would be easy to write a DSR extension to support the serial port from Basic. It is not hardware compatible with the TMS9902, though. If I implement a follow up board to this one at some point with an actual FPGA we could have hardware compatibility. Anyway for my purposes the USB port is hugely more useful, and a whole lot faster.

 

I personally no longer use my RS232 card, but I know a lot of other guys who do.

 

I think the primary goal of this card though is to provide a full disk and memory system for a standard TI console. The fact my game will be playable on it is a HUGE deal to me!

[+acadiel]

 

 

Thanks! The board does have a serial port, but it is not RS-232 voltage level compliant. An external level converter could be added. It would be easy to write a DSR extension to support the serial port from Basic. It is not hardware compatible with the TMS9902, though. If I implement a follow up board to this one at some point with an actual FPGA we could have hardware compatibility. Anyway for my purposes the USB port is hugely more useful, and a whole lot faster.

 

I'm really hoping that we can maybe standardize some sort of API with all these new RS232 solutions that don't go through the TMS9902. Or, if we're handing the data bus and DSR, I wonder if we can make the CPLD or FPGA "intercept" TMS9902 calls for legacy software.

 

Great job on this unit - I'm excited to see the final deliverable!!!

[speccery]

 

I personally no longer use my RS232 card, but I know a lot of other guys who do.

 

I think the primary goal of this card though is to provide a full disk and memory system for a standard TI console. The fact my game will be playable on it is a HUGE deal to me!

 

 

I'm looking forward to trying out your game Hopefully sometime next week I can do that.

[+adamantyr]

 

 

I'm looking forward to trying out your game Hopefully sometime next week I can do that.

 

Well, the binary I sent you just shows the intro and the title screen... There's a lot of other files it needs to work.

 

That said, the full game should be useful for the write sector subroutine testing as well.

 

The game engine is only 2/3 complete at the moment, as I still have to bring combat up from my old code base. I'm presently in test mode on the other parts to get them to a demo-able state for Fest West at the end of this month.

 

You can definitely be a play-tester once I get the game to a "playable" state!

[speccery]

 

Well, the binary I sent you just shows the intro and the title screen... There's a lot of other files it needs to work.

 

That said, the full game should be useful for the write sector subroutine testing as well.

 

The game engine is only 2/3 complete at the moment, as I still have to bring combat up from my old code base. I'm presently in test mode on the other parts to get them to a demo-able state for Fest West at the end of this month.

 

You can definitely be a play-tester once I get the game to a "playable" state!

 

 

That's cool - I thought this was an older game as it looked polished - I'd be happy to be a play tester, I can put my TI then in to good use

[speccery]

Finally posted the video about my "mystery" feature I've been teasing about.

ET-PEB directing sound chip writes to an external synthesizer

 

If you ever wanted to improve or differentiate the sound capabilities of the TI - now there is a way of doing that, taking advantage of the co-processing capability of the ET-PEB.

What happens here is that the ET-PEB captures writes to the TI's sound chip, builds a model of the sound chip status internally, converts the frequencies to notes, and then issues MIDI commands to an external synthesizer to play back the music and sound effects

 

I'm not aware of something like this being done for any retrocomputer in the past. surely there have been MIDI interfaces in the past, but they required dedicated software. The ET-PEB enables all most games to output MIDI without any changes to the games themselves

 

If you have suggestions of games to test and use in a video, please let me know. I noticed already that some titles can cause problems, I guess when a single sound channel is being used to play a chord by rotating through different frequencies the ET-PEB still has a bit hard time to keep up. Also MIDI bandwidth is limited. I'm planning to implement a chord detector for that purpose.

 

Let me know what you think!

[ti99iuc]

I could have a Roland Sound Canvas connected to the TI-99 and use programs like MIDI Master 99 too ? I understand well ?

It could be fantastic !

Don't like so much MIDI for sound effects into the games but some musics can be very good like the Alpiner one.

It could be borking also with a Speech Synth connected, or you will implementing the Speech Synth into the TinyPEB ?

 

I am in love for this peripheral !

[Sinphaltimus]

Oh wow, it's almost like an F18A for sound. LOL - Love it!

[Opry99er]

Thats pretty incredible, actually.

[+adamantyr]

Very cool!

 

I've been working with the TI sound chip for my CRPG, and I have to say... it's a bit disappointing. It's not a horrible sound chip (Apple IIe screech beeps anyone?) but it's incredibly limited. There's only a 10-bit range, for example, so 1024 frequencies maximum. The MSX sound chip was 12-bit. This alone adds two octaves. Plus the way the TI engineers had to tie it to the existing 3mz clock artificially pushes the octave range up, so base notes are nearly impossible to generate.

 

I like this approach a lot, I'm wondering though, is it possible to add a BETTER sound chip to the TI accessed through the CRU mapper?

[Opry99er]

There is the SID Blaster/Master card.

[speccery]

Very cool!

 

I like this approach a lot, I'm wondering though, is it possible to add a BETTER sound chip to the TI accessed through the CRU mapper?

If I were to add a better sound chip I would add a DSP and a sound DAC. Texas Instruments happens to be the company that produced the TMS32010, the first DSP to my understanding. My first self built DSP board was with the TMS32025. Edited April 8, 2018 by speccery

[+adamantyr]

Nice! I'd love to take a crack at programming sounds for that.

[speccery]

I decided to write a quick comment as I’ve been silent for a while - things have been busy at work and I have been traveling so unfortunately I haven’t been able to work on the project. I am about to board a flight to Asia, once I get back I hope to do some progress on the ET-PEB.

 

The next step will be to build a few more prototypes so that I can share them with some members of the community to do more testing...

[+Vorticon]

I was wondering if it would at some point be possible to include a parallel port on the ET-PEB. I am a big fan of the PIO port for ease of interfacing. I know that there are parallel-I2C interface chips out there, but it would be much better if no additional hardware was required.

[speccery]

Quite a few of the micro controller's pins are already exposed on pins. Might add up to 8 bits even... They could be used as a parallel port too, but that of course would require firmware support.

[speccery]

For what its worth I realised that the ET-PEB has been now covered twice in the RCR Podcast (Retrocomputing Roundtable), in episodes 168 and 172.

http://rcrpodcast.com

The first one (episode 168) I discovered just by listening - that was nice

The most recent episode 172 talks about the MIDI experiment I did, but I have not yet listened to what was discussed in there, hopefully something nice I got notification about it through twitter.

 

I discovered the RCR podcast probably around episode 70 or 80, and have been listening to it ever since. I can wholeheartedly recommend this podcast to anyone interested in retrocomputers, and I bet most of you here already are very much aware of its existence.

Edited May 25, 2018 by speccery

[djones60]

I've been lurker and following along with this. So I'm curious, has there been any progress?

Edited July 10, 2018 by djones60

[speccery]

Sorry for the extended silence. My time during the summer has been taken mainly by house move. It's been a long project, but pretty much done now. I am hoping I will start to have some time to work on the TI-99/4A soonish. Having said that I haven't yet wired up my development computers yet, let alone the TI, but I will get there.

[speccery]

Wow it's been almost two and a half years since I updated this thread... I'm now building three more boards in one go, since it seems I will be shipping out a few.

 

It's quite a project to build these things, although building multiple boards simultaneously does speed up the process, as I only need to find once the components and locate their places on the boards. As I was looking at the chips I have in my shelf (well in various somewhat unorganised boxes really) I started to remember where I was in the project. I was trying to choose which microcontroller to use, from a few pin compatible chips. I originally went with chip with 32K Flash ROM and Cortex-M3 core, but quite soon learned that the 32K was going to be a squeeze for the firmware.

 

My choice became easier since as I was looking at how many chips I have, there was only one model where I had three chips with more than 32K Flash. So I went on and built the boards with a processor I had not tested before. I just got the first board fully populated and tested, the firmware modified to support this new chip - and it worked on the first go! And when I say it worked, I mean that it worked to the extent the previous firmware worked - I probably want to spend a little time improving both the firmware and the DSR code. I was able to load basic programs from the SD card, and both tests for 32K RAM expansion and SAMS memory worked. 

 

The funny thing is that as I was building these, it almost felt like building a kit. It's been such a long time I worked on these that I had forgotten where I was, so I was re-discovering my own design as I went , referring to the schematics and BOM the same way as if I was following a kit.

[GDMike]

... and if you're like me, " why did I do that" ? Throwing that out....lol

[speccery]

On 1/2/2021 at 11:43 PM, GDMike said:

... and if you're like me, " why did I do that" ? Throwing that out....lol

Yes exactly, that was a my feeling with some components. I ordered an original batch of 10 PCBs (this is my practice) back in 2018, and later learned that I don't like to install SMD LEDs by hand. I have in subsequent different projects learned a bit more, so I would not design the board anymore the way I did.

[speccery]

I've continued to work on the ET-PEB firmware revisions. While at this I realised that even though the CPLD is very full (123 macrocells of 144 in use) and a pain to route for the software, I still might be able to cram in a few more features. And so I did, I was able to successfully add a two bit configuration register. The register is accessible by the microcontroller.

Bit 0: enables memory to appear in locations 6000..7FFF

Bit 1: when set, forces the board to what I call standalone mode.

 

Thus with bit 0 the ET-PEB is able to host 8K ROMs in the cartridge address space. Of course this must not be set if there is cartridge plugged in. This is no replacement for other, better systems, but still it may come in handy to have the ability to be able to load from the SD card or on-board memory a cartridge image. Actually I think I'm not write protecting the memory, so it also gives one 8K RAM in the cartridge space. Inspired by the nice TIPI DSR, it might be handy to have a TI-Basic command to load a given ROM file to the cartridge address space.

 

Bit 1, when set, puts the ET-PEB into a mode where it does not respond to memory read or write commands. So it pretty much disappears from the bus, although it may still handle CRU accesses, but I forget if they are readable or write-only. The primary use case for this mode is to be able to use the RAM chip by the microcontroller when  the board is not plugged in, which should be useful for development. Alas, this doesn't quite work yet without the connection to the TI, I think I still need some pull up resistors and perhaps reset control from the microcontroller to get things going without the TI connection. However, if connected to the TI, it does work, i.e. the TI no longer sees the board.

[speccery]

Worked a bit more on the ET-PEB to add support for disk directory reading. This was one of the major features lacking from the firmware. Now it works, although it does not correctly recognise the types of files. That will simple to implement, but requires opening all of the files and looking for the TIFILES header to determine things like record length, display/internal type etc. Perhaps I will do the detection when mounting a disk, so it would be a one time operation. I was initially not considering that pre-detection option since the small microcontroller doesn't have enough memory to spare to store the directories in RAM for all three disks (requiring 3*128*38 = 15K bytes). But then I realised that I was thinking this all wrong, I can actually use the unused parts of the external memory chip used by the TMS9900 for disk buffers. It's a bit slow and cumbersome to use this memory due to the way my DMA interface works, but in the scale of the speed of the TMS9900 still fast.

 

I've come to notice that development of the firmware is quite slow, since I need to study the documentation to understand how these things are supposed to work. Unix style unstructured files are definitely easier to work with  

 

Also debugging the firmware could be a bit faster, I'm going old school with just littering the code with printf statements. One convenience I have is that I can reprogram and the flash memory of the microcontroller without needing to power off the TI or loading test software again - the CPLD keeps the memory interface going nicely even while the microcontroller is in the weeds.

[speccery]

Well, as I work on the firmware, I found some other omissions which I've just forgotten or not been aware of in the past.

 

Added support for V9T9 format files. I just convert them to TIFILES format internally. In the process I also wrote a simple C program to detect file formats and dump fixed record files. I was thinking most files are in TIFILES format already, but I was very wrong: I was trying to run TurboForth off the ET-PEB, and it just wouldn't load the BLOCKS file. Debugging that made me realise the support for V9T9 format was necessary. In that process I also noticed that I had not implemented random record access, so added that too. My previous test cases all were of the type were programs would read and write files in sequential order, but TurboForth loads the blocks in random order, so added support for that. I was assuming that being able to run Editor/Assembler successfully was a pretty good test - and I suppose it is, but no random access there.

 

Loading fixed record length files in random order is simple, but variable record lenght files required a bit more code to parse the record lenght bytes. And I don't have any test cases for that, it seems all the files I had lying around are fixed record length files. I did write the code to be able to seek to the appropriate position, but without test files this untested?

 

I am almost certain I lack the same functionality for writes. I suppose I need to play around with TurboForth a bit to test.