Erik's ET-PEB

[+TheBF]

 

Never mind I just realised that my code was actually now calling internally a subroutine (during VDP access), and it messed up R11 i.e. the return address. I am still trying to get used to the fact that the TMS9900 does not have a stack.

 

My TMS9900 has 2 stacks. :-) Emulated of course, but it not too hard if you have a macro assembler.

 

If your assembler can make macros here is what I use.

 

RP is whatever register you choose for your return stack pointer.

 

With this macro you can CALL sub-routines to any depth and return is the same as normal, B *R11.

 

(shown here in Forth Assembler)

: RPUSH,        ( src -- ) RP DECT,  *RP   MOV,  ;
: RPOP,         ( dst -- ) *RP+      SWAP  MOV,  ;

: CALL,         ( dst -- )
                R11 RPUSH,       \ save R11 on forth return stack
            ( addr) @@ BL,       \ branch & link saves the PC in R11                              
                R11  RPOP, ;     \ R11 RPOP, is laid down by CALL, in the caller.
                                 \ We have to lay it in the code after BL so
                                 \ when we return from the Branch&link, R11 is
                                 \ restored to the original value from the rstack

It's more overhead of course but it might be of use for your testing.

[speccery]

Thanks! I am well aware of software stack possibilities (I've written two Forth implementations, one for MC68HC11 and another one for my Amiga 500 back in the day), but I was thinking my simple routine did not call any subroutines when it actually did Easy enough to fix.

[Sinphaltimus]

OMG you said Amiga 500 - Achievement unlocked - Awesome factor x10. Have you been following the Apollo Accelerator Vampire FPGA project at all? Sweet happenings right there.

Edited March 28, 2018 by Sinphaltimus

[speccery]

OMG you said Amiga 500 - Achievement unlocked - Awesome factor x10. Have you been following the Apollo Accelerator Vampire FPGA project at all? Sweet happenings right there.

 

 

I can't say that I have been following it, although I am aware of it. I think it based on an Altera FPGA and outperforms all the great CPUs from the past, including the MC68060. I don't have an Amiga 500 anymore - sold it back it in the day - but I am a proud owner of an Amiga 1200 with compact flash storage and 32-bit memory expansion, 8 megabytes if I remember correctly.

[FDOS]

Nice! My X4th99 requires a minimum of 256K AMS. I'm currently using a 1MB SAMS. In any case not compatible with my 3 x NanoPEB sidecars. I can, however, easily remove the 32k chip from my CF7A+ sidecar. Looking forward to another great TI-99/4A product to add to my collection. Keep up the excellent ideas and work.

[speccery]

Nice! My X4th99 requires a minimum of 256K AMS. I'm currently using a 1MB SAMS. In any case not compatible with my 3 x NanoPEB sidecars. I can, however, easily remove the 32k chip from my CF7A+ sidecar. Looking forward to another great TI-99/4A product to add to my collection. Keep up the excellent ideas and work.

 

 

Thanks - I am trying to keep up the project indeed. What is X4th99 - is that a Forth implementation or something else?

 

On the topic of keeping up the project I completed last night a port of the micro controller code of the ET-PEB to the LPC11U37 chip - it has 4x the flash ROM of the LPC1343. Due to differences in the I/O register setup and a somewhat updated software environment this became a bit more involved than I thought initially. Finally I wasted too much time on bug hunting the software, when I had a short of two pins on the TQFP44 packaged micro controller. The pin pitch is 0.5mm so the space between pins is just something like 0.2 mm - and it turned out very hard for me to see that there was a tiny blob of solder in there...

 

I am hoping that during easter I have some more time to work on this and to post a video of the current state of the project.

[FDOS]

 

 

Thanks - I am trying to keep up the project indeed. What is X4th99 - is that a Forth implementation or something else?

 

On the topic of keeping up the project I completed last night a port of the micro controller code of the ET-PEB to the LPC11U37 chip - it has 4x the flash ROM of the LPC1343. Due to differences in the I/O register setup and a somewhat updated software environment this became a bit more involved than I thought initially. Finally I wasted too much time on bug hunting the software, when I had a short of two pins on the TQFP44 packaged micro controller. The pin pitch is 0.5mm so the space between pins is just something like 0.2 mm - and it turned out very hard for me to see that there was a tiny blob of solder in there...

 

I am hoping that during easter I have some more time to work on this and to post a video of the current state of the project.

Yes, X4th99 was my figForth project before I was plagued with many personal problems and health issues, that took me away from my hobby for a couple of years. When I returned Mark Wills, who had helped me greatly with TI BASIC Plus (TIB+) was doing TurboForth (a Forth83 implementation), so I decided to help him with his Forth, which meant learning Forth83, after decades of figForth experience (Forth+ for the Geneve was released December 1993, but the expectation I had due to the MESS/MAME emulation did not come about, so I had less than a dozen registered users). It is where I learned to implement expanded memory for easy usage. Therefore, I came back to doing TI-99/4A development.

 

I will eagerly await the video, so I can better understand how it could bring X4th99 development back to the top of my priority list! I also gave up doing any SMT projects. I did successfully complete two Thierry Nouspikel IDE cards before the problem period, and then later switched to Fred Kaal's IDE DSR. both died, so sent out for repair never to return.

Edited March 29, 2018 by FDOS

[+TheBF]

Thanks! I am well aware of software stack possibilities (I've written two Forth implementations, one for MC68HC11 and another one for my Amiga 500 back in the day), but I was thinking my simple routine did not call any subroutines when it actually did Easy enough to fix.

 

I should have known better. And you are a Forth master as well.

I spent a lot of time with MAXForth on the 68HC11 in internal ROM.

Now I know. :-)

[speccery]

I should have known better. And you are a Forth master as well.

I spent a lot of time with MAXForth on the 68HC11 in internal ROM.

Now I know. :-)

I can’t say that I would be a Forth master, but I wanted to understand how it worked so I implemented it, on the Amiga first. You could say it was my project to learn both Forth and MC68000 assembly in one go...

Anyway I have always liked the elegance of Forth, and I read the Novix NC4016 article in the Byte magazine many many times over as I was totally impressed how a well Forth lent itself to hardware implementation. Later I’ve been impressed for example with James Bowman’s Forth implementations for FPGAs.

[speccery]

Yes, X4th99 was my figForth project before I was plagued with many personal problems and health issues, that took me away from my hobby for a couple of years. When I returned Mark Wills, who had helped me greatly with TI BASIC Plus (TIB+) was doing TurboForth (a Forth83 implementation), so I decided to help him with his Forth, which meant learning Forth83, after decades of figForth experience (Forth+ for the Geneve was released December 1993, but the expectation I had due to the MESS/MAME emulation did not come about, so I had less than a dozen registered users). It is where I learned to implement expanded memory for easy usage. Therefore, I came back to doing TI-99/4A development.

 

I will eagerly await the video, so I can better understand how it could bring X4th99 development back to the top of my priority list! I also gave up doing any SMT projects. I did successfully complete two Thierry Nouspikel IDE cards before the problem period, and then later switched to Fred Kaal's IDE DSR. both died, so sent out for repair never to return.

 

Sorry to hear about your health problems but it seems you’ve gotten better, I certainly hope do so. We aren’t getting any younger here... I can tell from my eyesight alone that aging is coming.

Thank you for sharing the background, interesting as always! I am in many ways a newcomer, so now that you spoke about TI Basic + I see another project I knew nothing about.

I am hoping to be able to do a decent video to explain my progress, I am excited about, although a lot of work remains.

[+TheBF]

I can’t say that I would be a Forth master, but I wanted to understand how it worked so I implemented it, on the Amiga first. You could say it was my project to learn both Forth and MC68000 assembly in one go...

Anyway I have always liked the elegance of Forth, and I read the Novix NC4016 article in the Byte magazine many many times over as I was totally impressed how a well Forth lent itself to hardware implementation. Later I’ve been impressed for example with James Bowman’s Forth implementations for FPGAs.

 

 

Cool. Yes the Forth as CPU idea is pretty nice. I love the way Chuck Moore made sub-routine returns for free on that design.

I have a papillio board here that I have wanted to put Bowman's J1 on it but I got distracted trying to finish this ANS Forth for TI-99.

 

Camel99 is getting there. File based Extendable kernel is 8148 bytes. I need to finish the File word set and then finish the docs. Then maybe I can tackle the J1.

 

Rumour has it I might have to go back to work... I thought I was retired. :-)

[LASooner]

OMG you said Amiga 500 - Achievement unlocked - Awesome factor x10. Have you been following the Apollo Accelerator Vampire FPGA project at all? Sweet happenings right there.

I have one, but haven't had time to set mine up yet. I got the Amiga 2000 CPU slot adapter for the Vampire so I can switch it back to stock quickly if I need to.

[FDOS]

Sorry to hear about your health problems but it seems you’ve gotten better, I certainly hope do so. We aren’t getting any younger here... I can tell from my eyesight alone that aging is coming.

Thank you for sharing the background, interesting as always! I am in many ways a newcomer, so now that you spoke about TI Basic + I see another project I knew nothing about.

I am hoping to be able to do a decent video to explain my progress, I am excited about, although a lot of work remains.

Yes, my health issues; high blood pressure, dental work neglected due to high cost, and cataracts in both eyes, caused great difficulties to the progress of my hobby development projects. I even managed to destroy some non-SMT PEB cards due to eyesight and fingers that could no longer touch-type, but could mangle IC's in a blink of an eye or cataracts that simulated the "blink of an eye"! I finally got the dental work done down in Mexico, and the cataract surgery in Phoenix, so vision is now excellent, but fingers are still my worse nightmare.

The TI BASIC Plus project came about due to the 16 RML bank SNUG HSGPL card in my full SNUG TI-99/4P (PEB) system. Tony Knerr developed a fast GRAM module loader that eliminated the problem of some GRAM/GROM modules not working correctly in RML banks other than 0 & 1, so why not use all those empty GRAM/GROM banks for TI BASIC programs that could be enhanced by other modules that supported TI BASIC Calls? The Speech Editor supported CALL SAY("WORDS"), the ED/ASM module supported many AL routines (of ones own creation, etc.), also PRK has many useful routines for TIB enhancement, along with TE II text to speech capabilities. FG99 is just not the equivalent to even a 4 RML bank HSGPL card, which I also have. :-)

[speccery]

 

Yes, my health issues; high blood pressure, dental work neglected due to high cost, and cataracts in both eyes, caused great difficulties to the progress of my hobby development projects. I even managed to destroy some non-SMT PEB cards due to eyesight and fingers that could no longer touch-type, but could mangle IC's in a blink of an eye or cataracts that simulated the "blink of an eye"! I finally got the dental work done down in Mexico, and the cataract surgery in Phoenix, so vision is now excellent, but fingers are still my worse nightmare.

The TI BASIC Plus project came about due to the 16 RML bank SNUG HSGPL card in my full SNUG TI-99/4P (PEB) system. Tony Knerr developed a fast GRAM module loader that eliminated the problem of some GRAM/GROM modules not working correctly in RML banks other than 0 & 1, so why not use all those empty GRAM/GROM banks for TI BASIC programs that could be enhanced by other modules that supported TI BASIC Calls? The Speech Editor supported CALL SAY("WORDS"), the ED/ASM module supported many AL routines (of ones own creation, etc.), also PRK has many useful routines for TIB enhancement, along with TE II text to speech capabilities. FG99 is just not the equivalent to even a 4 RML bank HSGPL card, which I also have. :-)

 

 

 

Sorry to hear about the fingers - don't really know what to say here - but good to hear you got other issues sorted out, at least mostly.

 

Quite a few acronyms here - what is 16 RML bank HSGPL card? I am familiar with GRAM, having implemented support for that myself. Does "RML bank" refer to the fact that GROMs can reside in many bases?

[speccery]

Did some work on the ET-PEB, finally there was some time. I've been now working on the LPC11U37 powered ET-PEB, which is good for development since there is plenty of Flash memory, but I have to say that the speed difference between Cortex M0 (LPC11U37) and Cortex M3 seems much greater than the clock speed difference would suggest... Well it is still pretty fast, and gcc works so the source code is pretty much the same.

 

I worked on a couple of things:

- Implemented "full" support for SUBLNK 0x14 to provide sector based access to file reading. The code is getting a bit messy as there now are three different methods of loading data from files: the DSRLNK opcode LOAD, DSRLNK opcode READ, and SUBLNK read sector. I will need to try to unify the code, but I have to say that the TI guys did not really do a great job when defining the disk interfaces. The sector based SUBLNK 0x14 is perhaps the best interface...

- With the above support I was able to run adamantyr's AMS test program successfully. I thought it was a test program, but it actually is a game

- Implemented a mount command which allows DSK1,2 and 3 to point to different directories on the SD card than just DSK1, DSK2 and DSK3.

 

With those changes the disk support is slowly getting readier. I still need to implement a couple DSRLNK opcodes (namely DELETE and STATUS) and the remaining SUBLNK opcodes. Some of the SUBLNK opcodes don't really make sense in my setup, since I am not supporting disk images (at least yet), only files on disk, so direct sector reading/writing operations or formatting do not make sense.

 

By the way, one potential advantage of the ET-PEB when compared to other disk systems is that it does not use any VDP RAM for disk buffers. Obviously to comply with TI specs the reads and writes put data to VDP RAM, but a FILES(x) command is not needed, since VDP RAM is not reserved for any ET-PEB operations. In other words the TMS9900 side DSR does not need any VDP RAM. The disk operations use the RAM of the microcontroller, and if I run out of that I have over 200K RAM available on the external RAM chip. Accessing that RAM from the micro controller is a bit like the TMS9900 talking to the VDP, as I have first have to setup the address on the CPLD before a read/write operation can take place. I can probably optimise those accesses further if needed, currently I seem to be getting about 100K bytes/s of bandwidth to the external RAM (shared with the TMS9900 - so care is needed). At this point of development that is not critical. It is worth noting that with a custom software interface the micro controller could stream data from the SD card to the RAM expansion of the TMS9900 with no CPU intervention.

[+Ksarul]

In answer to the meaning of the RML acronym, it translates to "REVIEW MODULE LIBRARY", a mostly hidden command in the TI operating system. On startup, the console scans the first 16 GROM Bases to see if one or more of them are populated. If it finds more than one present, it presents the menu items from the first GROM Base, followed by an additional entry "REVIEW MODULE LIBRARY." If you select the RML entry, the scan repeats, but now the selections from the second GROM Base present are displayed, along with the RML entry. You can continue to repeat this process until you eventually cycle back to the beginning, as the RML function is circular. The System99 Users Group (SNUG) High-Speed GPL (HSGPL) card was built with either four GROM Bases populated with GRAM or 16 GROM Bases. It also comes populated with 4 Banks of cartridge ROM space (as RAM) for each populated GROM Base.

[speccery]

In answer to the meaning of the RML acronym, it translates to "REVIEW MODULE LIBRARY", a mostly hidden command in the TI operating system. On startup, the console scans the first 16 GROM Bases to see if one or more of them are populated. If it finds more than one present, it presents the menu items from the first GROM Base, followed by an additional entry "REVIEW MODULE LIBRARY." If you select the RML entry, the scan repeats, but now the selections from the second GROM Base present are displayed, along with the RML entry. You can continue to repeat this process until you eventually cycle back to the beginning, as the RML function is circular. The System99 Users Group (SNUG) High-Speed GPL (HSGPL) card was built with either four GROM Bases populated with GRAM or 16 GROM Bases. It also comes populated with 4 Banks of cartridge ROM space (as RAM) for each populated GROM Base.

 

 

Thanks Ksarul for the exhaustive answer! I've actually been bitten by "REVIEW MODULE LIBRARY" feature in the FPGA design, in certain conditions I had a bug and (I don't remember right now - and don't want to look for that mid this message) the search got stuck and the menu did not appear.

I wonder what the High-Speed refers, though... The console GROMs will pull READY low for all the bases and all the addresses, before they figure out the address does not concern them - doesn't that make all GROMs and GRAMs slow unless there is mod in the console itself - or is this referring to something else? My FPGA designs have zero wait state GROMs, so they respond fast, but as has been discussed many times over the actual speed of GROMs isn't that important as the GPL interpreter takes its time to work on the data read from the chips, and that time pretty much diminishes advantages in memory access time.

[+Ksarul]

The High-Speed refers to the fact that all 8 GROM positions in each GROM Base are available on the HSGPL--and you can even remove the console GROMs, IIRC, which allows the speed boost.

[+OLD CS1]

What is X4th99

 

"X-Force" with a lisp and a shudder? (I can do better; get back to me later.)

[+mizapf]

To get an idea about both RML and the HSGPL, both are available in MAME. The RML feature is a bit more complicated when you want to switch cartridges that are not GROM only, requiring a bank latch that stores the recent GROM base to control the ROMG line.

[FDOS]

 

 

Sorry to hear about the fingers - don't really know what to say here - but good to hear you got other issues sorted out, at least mostly.

 

Quite a few acronyms here - what is 16 RML bank HSGPL card? I am familiar with GRAM, having implemented support for that myself. Does "RML bank" refer to the fact that GROMs can reside in many bases?

Yes, my health issues, other than my fingers, are under control. Not to the degree that I would prefer, because of side effects of some medications.

 

Yes, the RML (Review Module Library) is precisely that. The SNUG HSGPL card has 16/8/4 banks of REAL 64K GRAM, that is all GRAMS 0 - 7 with 8K each. I have two HSGPL PEB cards; one with 16 RML banks and one with 4 RML banks. Ah, I see others have already explained the RML.

[speccery]

A quick update to the teaser about a new feature I mentioned earlier - after working on the new feature last evening I couldn't help but look at it again this morning before leaving for work (good thing I woke up early). I realised that I had done a stupid mistake yesterday: the latest change to firmware was not saved before compiling. With that and another optimisation I did get this thing working. To me this is a very cool feature and I got this nice sense of accomplishing something.

 

Now I need to find some time over the weekend to post a video to get your comments on it... and the general progress with the ET-PEB.

[speccery]

I posted one video - this became quite different than I though and it does not talk about the "mystery" feature yet. Jump towards the end if you want to see one new feature... It became some kind of explanation of the TI-99/4A memory map...

TI-99/4A Memory Map and ET-PEB

[+adamantyr]

Very cool!

 

I like the flat profile of the unit too, not having the RS232 like the nanoPEB does is a huge space saver. And I'm sure someone with a 3D printer could make a case for the finished product.

[speccery]

Very cool!

 

I like the flat profile of the unit too, not having the RS232 like the nanoPEB does is a huge space saver. And I'm sure someone with a 3D printer could make a case for the finished product.

 

 

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.