Erik's ET-PEB

[GDMike]

Great news indeed ?

[+Ksarul]

Definitely go slow for a while. This one doesn't let go of the body quickly. . .or cleanly. Some side effects don't become obvious for a month or more (like weakening of the heart muscle).

[djones60]

On 3/6/2021 at 11:21 AM, speccery said:

 I contracted COVID some time ago, still fighting the disease. It’s now day 9. I think this is the mild version (so far) but with so many days on this, it is a bit consuming. At least I got my appetite back a couple of days I ago, hopefully it’s a sign of something. But the fever keeps me unable to

do much, even if it isn’t too high.
 

The only TI related thing I have done is that I received this week a hard copy of @Lee Stewart’s fbForth manual which I ordered sometime ago. I haven’t read it yet, but having a real manual is nice and very exceptional.

Glad you are feeling at least a little better and it wasn't a serious case!!  Just keep an eye on yourself and try not to over do it for a while.

[kl99]

all the best from my side as well to you Erik!

I read the last months posts of this thread and only want to mention something about your possibility to load a file (cartridge) into the >6000  - >7FFF memory area.

There you mentioned it is not write protected and therefore might act as 8K ram slot.

While this write possibility is wanted in most places please consider

- there are cartridges that use writing to certain memory addresses in that area in order to switch their rom banks.

- there are cartridges that do a write because of a bug, which is not making an impact if the cartridge space is write protected (like on the actual hardware with an actual cartridge).

- there is Mini Memory, which is (if I am right) also having some special writes for its functionality. Which is one of the few original cartridges actually using part of this address range to store data.

 

Enjoy working on these projects, but also take it easy with your recent infection.

 

Edited March 15, 2021 by kl99

[+TheBF]

8 hours ago, kl99 said:

all the best from my side as well to you Erik!

I read the last months posts of this thread and only want to mention something about your possibility to load a file (cartridge) into the >6000  - >7FFF memory area.

There you mentioned it is not write protected and therefore might act as 8K ram slot.

While this write possibility is wanted in most places please consider

- there are cartridges that use writing to certain memory addresses in that area in order to switch their rom banks.

- there are cartridges that do a write because of a bug, which is not making an impact if the cartridge space is write protected (like on the actual hardware with an actual cartridge).

- there is Mini Memory, which is (if I am right) also having some special writes for its functionality. Which is one of the few original cartridges actually using part of this address range to store data.

 

Enjoy working on these projects, but also take it easy with your recent infection.

 

And also the Editor Assembler Super Cart with 8K ram at >6000.

[+Ksarul]

15 hours ago, kl99 said:

all the best from my side as well to you Erik!

I read the last months posts of this thread and only want to mention something about your possibility to load a file (cartridge) into the >6000  - >7FFF memory area.

There you mentioned it is not write protected and therefore might act as 8K ram slot.

While this write possibility is wanted in most places please consider

- there are cartridges that use writing to certain memory addresses in that area in order to switch their rom banks.

- there are cartridges that do a write because of a bug, which is not making an impact if the cartridge space is write protected (like on the actual hardware with an actual cartridge).

- there is Mini Memory, which is (if I am right) also having some special writes for its functionality. Which is one of the few original cartridges actually using part of this address range to store data.

 

Enjoy working on these projects, but also take it easy with your recent infection.

 

I think there are even a couple that write to that space on purpose and then check the value there--as a protection mechanism. If the value is the written one, the program stops, and if it is the original ROM value, it works fine.

[speccery]

Thanks for the comments. I am not sure if the ability to put RAM (or write protected RAM) in the cartridge space by the ET-PEB is a good idea. Without some sort of conflict detection it would be easy to have a bus conflict between the ET-PEB and a normal cartridge. But since it was such low hanging fruit, I gave it a go. I think in the current version of the CPLD I already removed that mapping.

 

I am thinking about making a new board revision of the ET-PEB. I would like to add TIPI support and replace the CPLD with a small FPGA. The FPGA would enable me to add full 1 meg of SAMS memory with ease, and the TIPI interface would be simple to bring in too. Development of fully featured file system for the ET-PEB seems to take quite bit of time, and TIPI already handles a lot of that very well. I could then use my time for other interesting features, such as adding the J1 Forth CPU in there.

 

[GDMike]

In my SNE program, I don't want >6050->6100 touched. So I copy that data I have stored there, as it's program code. And I put a copy off to >F000. I always just grab that copy and repeatedly place it back at certain times.

This way, I don't care if it's trashed for some reason.

Because I found that I couldn't just flip a read/write switch on my memory chip.

 

Edited March 16, 2021 by GDMike

[speccery]

On 3/15/2021 at 9:13 AM, kl99 said:

all the best from my side as well to you Erik!

I read the last months posts of this thread and only want to mention something about your possibility to load a file (cartridge) into the >6000  - >7FFF memory area.

There you mentioned it is not write protected and therefore might act as 8K ram slot.

While this write possibility is wanted in most places please consider

- there are cartridges that use writing to certain memory addresses in that area in order to switch their rom banks.

- there are cartridges that do a write because of a bug, which is not making an impact if the cartridge space is write protected (like on the actual hardware with an actual cartridge).

- there is Mini Memory, which is (if I am right) also having some special writes for its functionality. Which is one of the few original cartridges actually using part of this address range to store data.

 

Enjoy working on these projects, but also take it easy with your recent infection.

 

Thanks @kl99!

Yes it's true that cartridge area, if supported, needs to have write protection. Actually in both my FPGA and StrangeCart projects the cartridge space is write protected, and writes to this space cause cartridge bank switches based on the address being written to.

 

Mini Memory is an interesting cartridge indeed, but also quite simple: >6000..>6FFF is 4K ROM, and >7000..>7FFF is 4K battery backed up RAM. The RAM area works as a normal RAM. Then of course the cartridge has some GROM too. The StrangeCart emulates all of these functions. One thing I should add to that is the ability to store the RAM region >7000..>7FFF to Flash when the system is powered off.

 

[speccery]

I realised that in case someone is interested in this thread, there was an update after a long last as I wanted to make Snake Snake work in my setup. Originally in the Snake Snake thread.

 

Perhaps a bit off-topic, but with regards to CALL FILES(0) my ET-PEB board does not use any VDP RAM for buffers, in fact I haven't even implemented CALL FILES. I have not worked on that project for a while, except now that I wanted to play Snake Snake and discovered and fixed a bug related to this. I looked at the scratchpad RAM pointer to the top of RAM useable by BASIC, and with ET-PEB is the top of VDP RAM, i.e. 16383. This is not a surprise, as my simple and stupid DSR does not allocate RAM on the TI side. The file buffers are kept in the RAM of the microcontroller. That probably means the ET-PEB will not support some software as its not leaving any breadcrumbs behind either, like Tursi mentioned for classic99.

 

As an additional thing, while working on the StrangeCart I have noticed that when saving programs from Basic, my ET-PEB does not allow overwriting a file, although this is possible with js99er.net so I assume the real disk hardware (which I have never used) also allows for that. Thus need to update the firmware for that part.

 

[+jedimatt42]

If it helps, TIPI had the same CALL FILES issue, and here is my CALL FILES code for the DSR : https://github.com/jedimatt42/tipi/blob/296ec219f3910e3d3c4e60d50dc0d0af199f6b8b/hardware/dsr/basic.a99#L68

 

Also adjusted the default VDP stack in the powerup routine: https://github.com/jedimatt42/tipi/blob/296ec219f3910e3d3c4e60d50dc0d0af199f6b8b/hardware/dsr/powerup.a99#L30  so it comes up in the same state as a TI floppy controller would... per community recommendation at the time. 

[speccery]

On 12/8/2021 at 3:34 AM, jedimatt42 said:

If it helps, TIPI had the same CALL FILES issue, and here is my CALL FILES code for the DSR : https://github.com/jedimatt42/tipi/blob/296ec219f3910e3d3c4e60d50dc0d0af199f6b8b/hardware/dsr/basic.a99#L68

 

Also adjusted the default VDP stack in the powerup routine: https://github.com/jedimatt42/tipi/blob/296ec219f3910e3d3c4e60d50dc0d0af199f6b8b/hardware/dsr/powerup.a99#L30  so it comes up in the same state as a TI floppy controller would... per community recommendation at the time. 

Thank you for sharing this, very useful!

[speccery]

The last pandemic club call I participated made me even more interested in testing Force Command by @jedimatt42 again. Force command uses SAMS memory which is great. But my only SAMS for the real iron is the ET-PEB, which only supports 256K SAMS, while it seems most current projects require the full 1024K.

 

I have in the past already tried to synthesise a version of the CPLD logic which would enable using a 2M RAM chip, which is what my design requires for 1M SAMS. I need more that just the SAMS memory space since I store other stuff there, such as the DSR. Anyway, I have not been able to make the VHDL design fit into the CPLD with 21 bit address bus. I guess in some of the previous messages here I have expressed my frustration about that  . 

 

Coincidentally @ti99iuc mentioned my project in a Facebook thread, which gave me the nudge to look into the board again. 

 

Sometimes a pause in a project helps. After this long pause (I guess we measure it in years), it took me yesterday only a few hours to come up with a design change which did fit! And not only that, I was able to also fit a slightly better version of the sound chip capture hardware. I also found a PCB bug, the ET-PEB PCB is laking a few millimetres of wire to one of the expansion pads I left unused, and I was using it to test. After soldering two wires to the actually wired expansion pads the design now works with full 1M SAMS! This is great! The only downside is that the 2M SRAM chips are bloody expensive, at around 20 EUR each without tax. But that's a minor gripe, I think this is not too bad for this 3 chip design (MCU, CPLD, RAM).

 

I haven't tested the MIDI generation again yet, but I want to believe it will work too. Will try to do it today.

Edited February 13, 2022 by speccery

[speccery]

The MIDI generation works! I really enjoyed playing Parsec using Novation Circuit Tracks synthesizer as the audio generator over MIDI. I should redo my video about this, since this time I had reverb and stereo delay enabled, which made the audio much more interesting. I have now many more powerful synths than in the past, so the old TI games can really be a nice source for inspiration when noodling with synths. TI Invaders' standard beeps when the whole crop moves left or right also sounds like the start of a beat. 

 

I am happy that I have both features - 1M SAMS and audio chip recording - in the same CPLD design. I'm now wondering if I could also transform this into a TIPI interface (would need to be done using the MCU, the CPLD is too full) or hardware emulator of the actual TI disk drive. The concept of recording I/O chip writes into regions of RAM could be used to emulate a whole bunch of stuff.

 

Nothing goes without problems, the TI computer I used as my testbed for the past year became unstable, and I spent a good while debugging software before understanding the computer had become unstable and the software was fine. I moved my boards (StrangeCart and ET-PEB) to another TI, and they worked perfectly from the get go. So need to disassemble and do some maintenance on the computer I've been using.

[speccery]

I got covid again. Luckily it seems to be much milder this time around, but still causes tiredness and makes it hard to focus.

 

Before I got it I started to work on my first actual FPGA board design. It's the first time I'm using Kicad, so that's pretty exciting but lots of learning to be done. Luckily I've been getting advice from @matthew180 how to do things in Kicad.

 

My intention is to first make a simple prototype board, which would connect to the side port of the TI. The plan is to include on the board buffers to connect the signals to 3V, have the FPGA and some SRAM, plus some functions required for the FPGA board (or any board for that matter) to work such as regulators, crystal, etc. I'm going to include a Raspberry Pi expansion header as well, so that this thing could also function as TIPI, and could be programmed by the PI. I am still at schematic design stage. The idea for the board is that that it would be approximately 10cm*10cm board with 4 layers (there PCB price doubles if a dimension exceeds 10cm). For the board design my plan is to not make it pretty, but something that is hopefully relatively easy to debug. There will be quite a few components I have never used before in my own board designs, so the risk level is quite high...

 

I am designing it around the ICE40HX1K FPGA in 144 pin TQFP package, which is one of the few chips one actually can buy right now.

@FarmerPotato might be interested in this too, as he has loads of these to my understanding. This is a small FPGA in terms of logic capacity (and cheap!), but I will also try to make the board compatible with the larger ICE40HX4K chips. The two have pretty much the same pinout. I have two of these 4K chips I ordered a few years ago, currently they are not in stock anywhere as far as I know.

 

I did synthesise the ET-PEB's XC95144XL chip's logic for the ICE40HX1K FPGA, to see how much capacity it would consume. Since I wanted to use the open source yosys/nextpnr toolchain I converted the code from VHDL to Verilog. The design uses 228 LUTs, or 17% of the capacity, and would run at a maximum frequency of 186MHz (completely irrelevant). I would not design the logic the same way as for the CPLD, I think once optimised for FPGA it will consume far less resources, but nice to see the original design will fit with ease.

[+TheBF]

20 minutes ago, speccery said:

I got covid again. Luckily it seems to be much milder this time around, but still causes tiredness and makes it hard to focus.

Sorry to hear that.

I have read that vitamin D seems to be important in fighting this thing. With winter in the north we are not getting enough sunshine typically. Might be worth a try.

I suspect it's whatever the next variant is in your part of the world so your previous immunity is just slightly off for the new form.

 

Out of curiosity did you receive any of the vaccine products that are available?

I did because I have most of the known factors that lead to "bad outcomes" as the doctors put it. (death  )

(AB- blood which is the worst, over 65, male) 

 

[speccery]

7 minutes ago, TheBF said:

Sorry to hear that.

I have read that vitamin D seems to be important in fighting this thing. With winter in the north we are not getting enough sunshine typically. Might be worth a try.

I suspect it's whatever the next variant is in your part of the world so your previous immunity is just slightly off for the new form.

 

Out of curiosity did you receive any of the vaccine products that are available?

I did because I have most of the known factors that lead to "bad outcomes" as the doctors put it. (death  )

(AB- blood which is the worst, over 65, male) 

Thank you. The omicron variant is the dominating version here. Last year, when I got It first time (probably delta), it was before the vaccines were available (I forget the details, but at least unavailable to my age group without risk factors). Here in Finland we did it by age groups and starting with the most vulnerable people first. Since I had covid already once in a pretty bad way, but not requiring hospitalisation, I was hoping I had developed strong immunity. But as we know, the immunity does not necessarily last long, and also the variants can still get you. Anyway I got all the vaccines as fast as I could after covid, but the local rules required some waiting before I got the shots. I got my third jab just a little over a week before contracting the virus again, so that booster probably was not fully active yet. I am a big advocate of getting vaccinated, was before having the disease and even more so afterwards. The ones I got were the vaccines from Pfizer if memory serves me right. I am of the opinion that everyone will eventually be exposed to covid, so it is a question on whether you want to have it with or without vaccines.

[+TheBF]

Yes it seems everyone will get this thing now.

Some research indicates that you should now have excellent immunity with the vaccines plus the "wild" virus providing the broadest range of antigens.

So with a little luck, this could be the last time you get sick with this one.

 

On another note I am totally envious of your work with FPGAs.   

Keep posting. It's fun to read about your work.

[GDMike]

 I'm so sorry to hear about your fight again. Get better soon. 

Edited March 4, 2022 by GDMike

[speccery]

On 3/4/2022 at 4:59 PM, TheBF said:

On another note I am totally envious of your work with FPGAs.   

Keep posting. It's fun to read about your work.

I would encourage you to try out yourself. With your knowledge of Forth etc it should not be hard to get going. If I get this project implemented the way I am intending, it could be an interesting platform to run for instance a Forth CPU. For that we should use larger FPGA chips than the 1K LUT chip though. With the open source toolchain it is straightforward to try things out, for example on a Raspberry pi, without installing gigabytes worth of software. 

 

Today feeling much better, I think I have beaten covid the 2nd time as well.

[+TheBF]

1 hour ago, speccery said:

I would encourage you to try out yourself. With your knowledge of Forth etc it should not be hard to get going. If I get this project implemented the way I am intending, it could be an interesting platform to run for instance a Forth CPU. For that we should use larger FPGA chips than the 1K LUT chip though. With the open source toolchain it is straightforward to try things out, for example on a Raspberry pi, without installing gigabytes worth of software. 

 

Today feeling much better, I think I have beaten covid the 2nd time as well.

Cool.  I have an RPI 400 so I have a beginning.

I don't know but it makes me wonder if the J1 processor could be implemented in 1K LUTs.  It's only 200 lines of Verilog.

 

https://github.com/jamesbowman/j1/blob/master/verilog/j1.v

 

[+FarmerPotato]

5 hours ago, TheBF said:

Cool.  I have an RPI 400 so I have a beginning.

I don't know but it makes me wonder if the J1 processor could be implemented in 1K LUTs.  It's only 200 lines of Verilog.

 

https://github.com/jamesbowman/j1/blob/master/verilog/j1.v

 

The IceStick has the HX1K and holds the J1A. Limit to your program though. I used it as a platform to try SPI from Forth and write a FAT32 SD card driver. Only 24 IOs though. After that I moved to BlackIce2 which has 56 IOs. 

[speccery]

On 3/6/2022 at 2:31 AM, FarmerPotato said:

The IceStick has the HX1K and holds the J1A. Limit to your program though. I used it as a platform to try SPI from Forth and write a FAT32 SD card driver. Only 24 IOs though. After that I moved to BlackIce2 which has 56 IOs. 

On the board I'm designing the ICE40HX1K interfaces to the TI's side bus, SRAM and Raspberry Pi I/O. Those consume some logic resources too. Not sure if the J1A fits in anymore with those interfaces, but we will see. I will certainly try at some point. I have been planning to use 8-bit wide external SRAM to make the board design easier, but for J1A it would be nice to have 16-bit wide SRAM... At least as long as I am working on schematic entry, it will be no problem to increase the bus width to 16 bits  

 

A minor comment to the IceStick I/O pin availability (this is a bit obscure, but just noting this for my own benefit): 
If one wants to use more I/O pins, of course it is possible to solder tiny wires to the TQFP chip pins directly. In general this is tricky, but as I checked it seemed that some of the FPGA's unconnected I/O pins are actually in the corners (first/last pins on a side) of the 144 pin package, so they would be "easy" to wire up. The corner pins would be:

1     Already connected to DCDn

36   PLLVCC 

37   PIO2_04 available!

72   SPI_VCC 

73   PIO1_22 available! (TDI secondary function)

108 VPP_2V5

109 VPP_FAST

144  PIO0_22 available!

 

So this way 3 more I/O pins could be had quite easily. The other pins would be much harder to solder into, but I think it would be possible to solder two adjacent I/O pints together, solder in a wire, and use only one the pins. A hack for sure  

[speccery]

Hi @ti99iuc I added some documentation to GitHub please see if you find this at all helpful.