Jump to content

speccery

Members
  • Content Count

    562
  • Joined

  • Last visited

Community Reputation

938 Excellent

About speccery

  • Rank
    Dragonstomper

Recent Profile Visitors

4,476 profile views
  1. 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.
  2. I actually live in Finland - I assume the "Tak" in the beginning refers to "Tack" which would be thank you in Swedish The Finnish word is weirder, its is "Kiitos". I used to be fluent in Swedish too, but nowadays everybody is using English... After sending I realised that you probably are already familiar with the Xilinx tools, since you've got the board and all. Xilinx is providing a VirtualBox image installer for Windows to support ISE 14.7. That's what I was mostly using, although I now have a ISE 14.7 installation on my Windows 10 box. It requires changing a DLL to run properly, the DLL comes with ISE 14.7. I don't know what operating system you're using, so again this might not be relevant for you.
  3. https://github.com/jamesbowman/swapforth is the original creator of swapforth and the J1. The J1B is the 32 bit version. Actually now looking at this, James targeted the Duo. I thought I did a port, but apparently not. I have ported it to the BlackIce-II board, but that's not a Xilinx project. Take a look at the PDF document in https://github.com/jamesbowman/swapforth/tree/master/j1b/doc, James has done a very good job at documenting it. I took a quick look at the top level verilog file, Xilinx-top.v. It appears that if WANT_VGA is not defined, the design does not use the external SRAM. In that case it's pretty much only using the on chip resources of the FPGA itself. Porting it to the Pro would be simple then, it's mostly a matter of making a user constraint file for the Pro board and adjusting the top level verilog code to match the Pro board. If the external clock frequency is the same as with the duo, then there's no need to even modify the PLL settings. I assume the Pro also has FTDI chip to provide USB serial port. So the steps would be something like: 1. Install Xilinx tools (I use ISE 14.7) 2. Find any existing demo project for the Pro board. Run something like "rebuild all" for the demo project to verify that the toolchain is working. 3. Load the bitstream generated in step 2 to the Pro board and check that the board does something. It's easy to write the steps above, but 1 & 2 will take a bit of time and patience, and learning curve. After that you would be able to actually port the project: 4. Use the papilio Duo project as basis. 5. Replace the UCF file to match the Pro board (probably the Pro's default UCF file is good to go). The same file used in step 2 should be good. 6. Modify the top-level verilog file. If memory serves me right the Pro has a SDRAM chip. You'd want to set its control signals to a known static state, to keep it the SDRAM silent and not having floating control signals. The same goes for any other unused peripherals on the board. A basic J1 environment really doesn't need much more than serial port (TXD and RXD), in coming clock signal and reset. The remaining pins can be left as inputs, or as outputs driving 0 or 1 as appropriate to any unused peripherals on the board to keep them out of the way. 7. Synthesise the modified design. Same process as in step 2. 8. Fix bugs to the point that the synthesis works. Basically rinse and repeat step 6&7 as long as it takes 9. Load the generated bitstream, hope it works, and enjoy. If not, it's back to step 6 I can also try to make a port. It shouldn't take more than an hour, could be much less, but since I have no way to test it... could be a bit frustrating and really shooting in the dark. I don't know when I could try this, hopefully next week as I am away from home the weekend.
  4. That's weird - so you were testing with the same (or similar) benchmark Perhaps it's not so surprising, it's a simple thing to do to bring a computer to its knees... I am aware of the RISC V development but haven't really dived in. Is the nano you mention a development board of some sort? I haven't updated it recently, but I also have the StrangeCart thread discussing my proof of concept project of by just hooking a microcontroller to the TI, and connecting to the bus with just software. The microcontroller has two cores, the other core is busy monitoring the TI bus but the other more powerful core could run Forth for instance. At 100 or 150 MHz it would give a decent performance. I am actually thinking of doing another iteration of that board, to also include FPGA chip. So let me ask you a question: would you be interested in a Forth accelerator for the TI? Either on the module port or expansion bus. The module port is easier since the no connector is needed. If that was another version of the StrangeCart it would be on the module port, and could be a pretty simple board, just what I have already done plus FPGA running J1. I was looking at my notes, I noticed that I have actually tested J1B on the Papilio Duo board. It was two years ago. I also located that project, but haven't tried it again. It is a 32 bit version of the J1, running at 80 MHz.
  5. I found the work I did two years ago, when I ported the J1A to the BlackIce-II board. This is a cheap FPGA board, sporting the low end Lattice ICE40HX4K FPGA. I have used the Icestorm toolchain for synthesis, with the nextpnr place and route tool. I am running J1 at 48MHz. According to the timing analysis, the J1 could run at 73MHz at this low end FPGA. In case you're interested, the memory space contains just 8K of on-chip FPGA block RAM (half of the RAM on this small FPGA). The core uses 1080 LUTs out of the 7680 available (Icestorm enables unlocking the chip, Lattice 4K FPGA actually has 8K LUTs on board). @TheBF and @Lee Stewart should find this interesting... I am quite blown away myself. The benchmark results are amazing: 100 iterations of the Fib2-bench completed in 13.5 seconds... So one iteration takes 0.14 seconds. I couldn't time it without a loop. The BENCHME word was on the benchmark page. The FIND word was new to me, and it did not seem to work right. But the old fashioned tick did the trick. This is 1000 times the performance of TurboForth (well not quite, just over 700 times). On a single core taking a fraction of a low end FPGA. ' FIB2-BENCH 100 BENCHME .................................................................................................... 100 Iterations. ok And below it the output of "see fib2". (I am trying to use the spoiler thing for the first time, let's see if it works). That's what you get when your machine code is Forth. I did a simple benchmark run, as below, running 100 million iterations. This took just under 14 seconds. 7 million iterations per second. : thousand 1000 0 do loop ; ok : million 1000 0 do thousand loop ; ok million ok ' million 100 benchme .................................................................................................... 100 Iterations. ok And the code:
  6. I didn't have time to work on the ET-PEB this weekend, will try to continue to work on it during the evenings. I got a bit sidetracked with a Forth exercise, thanks to this fun discussion with @TheBF I took a trip down the memory line, to see how the Forth I created for the Amiga was. I bought some years ago an A1200, must be five years ago by now. Haven't used it much, but I do have my Forth on it. The Forth is not really finished, according to comments in the source code I have started and stopped the project in December 1989. It's been a while... I think I have the same assembler I used to write that also on this machine so I could continue working on it (I was able to copy material from an old floppy I had from my Amiga 500). So I did run a benchmark I found here, the Fibonacci 2. On my Forth from 30+ years ago the Fibonacci 2 benchmark took approximately 1.6s (my Amiga 1200 has turbo card in it with a 40MHz MC68EC030 CPU - I have a 50MHz 68030 that I want to install, but haven't dared to pull the old CPU from its socket...). The 40MHz CPU runs so hot that I can feel it's location even through the desk On the Amiga the CPU slot is under the machine. I tried the same on Camel99 i.e. Foxshell, it was about 1min 55s. Not a surprise there, the 68030 appeared 11 years after the TMS9900. I wanted to compare both of these to the J1, but that needs to wait for another day. With all of this fooling around with Forth I am also thinking it would be nice to test how fast it would run on the MCU on the ET-PEB. I think it would beat the Amiga hands down. And I assume the J1 @ 50MHz would beat the ET-PEB's MCU.
  7. I have a Papilio Duo board, but not the Pro. If you provide a pointer to that project, I could try it out and port it to the Duo if possible. I haven't tested J1 on Xilinx chips, but for sure it will work on those too. I have played with the J1 only on small Lattice FPGAs. The stack implementation there is remarkable: in the J1 on those chips James Bowman (the designer) is using long shift registers (which shift in 16-bit quantities) for data and return stacks. There are no stack pointers at all. The small Lattice FPGAs don't have true dual port memories (their RAM blocks have one write and one read port, so they are dual port but no simultaneous writes or reads), so the stacks are implemented in the logic array. This implies that the stacks have to be small. I suppose for multitasking one could just dump the small stacks in their entirety to normal RAM. The Icy99 is running on more capable bigger chips, so there multitasking could be done on a per processor basis. In addition, the FPGA I'm currently using for development (ECP5 85F) could easily include at least four (if not eight or even more) J1 subsystems. Would be a fun exercise to see how many could fit in there...
  8. Well that video nearly left me speechless... I don't want to see the giant bot doing that for human beings... But the counter is cool. You've clearly put Forth to actual hard work! I've only been tinkering with it. I really need to test the stuff you provided. I got side tracked today: I'm also thinking about the next version of the ET-PEB. I don't know if you're familiar with it, but my current version is basically SRAM + CPLD + MCU. The bloody CPLD ended up being too small for what I wanted to do. I did manage to cram SAMS memory paging in it as well as a DMA channel so that the MCU can access the SRAM directly. So for the next version the CPLD probably needs to go, and I'll put a proper FPGA instead. But the interesting FPGA chips are larger chips in terms of pincount. I needed to test that out, and today I assembled this from parts I ordered many months ago: I am getting better at SMD soldering, so I got the whole thing hand soldered in something like 2 hours. After moving last year I don't exactly know where my Atari 800XL is, but I actually built this Ultimate Cart just to see if the assembly job is doable. It is - in single quantities. This one is using Altera/Intel Max 10 FPGA, in 144 pin TQFP package. I don't know if this fully works (need to find that Atari) but I did get the FPGA programmed and at least the FPGA works and LED flashes. It is remarkable that it's a two layer board. I went with a 4 layer design for the ET-PEB. In this case it is helpful that the FPGA here has many more pins than actually needed, making PCB routing easier. Anyway, I suppose my next version will be something similar: 144 pin FPGA, a set of buffers for 5V - 3.3V translation, and some support chips. Even a small FPGA can host the J1 core I look forward to trying out Camel99. TurboForth is very nice too. thanks for the pointers.
  9. Thank you very much! I will take a look and appreciate the help and insights. Haven’t had the time yet to look at the latest version you posted. I have some history with Forth: first on my ZX Spectrum I had Abersoft Forth, I was probably around 15 then. Lots of tape loading back then... I have implemented Forth for a MC68HC11F1 microcontroller board I built 20 years ago (had to check that, I thought it was 10 years ago, but actually around 2002). This was a port of MC6800 FIG Forth if I remember correctly. And indeed I used Forth to test the system Also back in the day when I had an Amiga 500 I wrote a Forth for it. This one was not a port of anything, just my own version. For these two Forth systems I did not have disk support, so some catching up to do for me. More recently I have tested the J1 Forth FPGA processor on a couple of FPGA systems. It is a fascinating system, similar to Novix NC4016 as I recall. I intend to add the J1 to my Icy99 system as a coprocessor.
  10. Good stuff A quick question: does your Forth implementation include the word SEE or something similar to show how words are defined? Would be handy for me to see how those words work. What you've done is very useful for testing. This may a stupid question, but do you support loading Forth code from the disk with the LOAD keyword or something similar? I'm not in front of the TI right now so cannot check easily...
  11. The copy command limited to DV80 format files is fine with me, just an observation about the limitation. I was able to test the delete command with DM2K, and it worked fine. As I was looking at the code I realised I missed that PAB opcode, but it's now done. My testing is indeed very limited, to this FIAD system I am building, so do take my findings with a grain of salt The new version works as expected, COPY and MORE work now with the entire file - thank you!
  12. Thank you @TheBF, I will give this a go! Sorry, my message was not clear. The mount command is a specific feature of ET-PEB. It is used to mount a directory on the SD card as a disk for the TI-99/4A. My note about append was for me, I need to implement that on the ET-PEB side. I still miss that feature. I noticed something else, with the previous version of Foxshell, regarding DEL command: (note that the problem may well be due to the way ET-PEB works, although classic99 seems to have the same behaviour.) If I try to delete a file, Foxshell attempts to open that file first, as a fixed record length file. Since the file I was trying to delete was a variable length file, the open fails. The delete command is never issued. Thus DEL command does not seem to work. Is the COPY command supposed to be able to work with other files than DV80 files? I tried to copy the Foxshell executable, but that did not work - it was trying to open the file as variable record file, and that failed as the file is a fixed record one.
  13. A very good comment! Sadly, I don’t have the a real PEB or disk drives... I only have what I have built. And the TIPI in my FPGA setup, but currently no connection from the real console to the TIPI. That I can build though. I suppose one hardcore option would to build floppy drive hardware emulation in a microcontroller or FPGA. When you mention using TI Disk controller ROM - is there a way to run it with classic99?
  14. @TheBF Thanks again for providing Foxshell! I've now done a bit of testing. I noticed that the copy command misses the last line. I've used the DSK1.AEMSSYS file as the test file (included in Classic-99). Please see the screenshots below, they partly overlap. Doing MORE DSK1.AEMSSYS shows 8 lines, while TurboForth FTYPE on the same file shows 9 lines (although the last line seems to be trash). Anyway, doing COPY DSK1.AEMSSYS DSK2.A drops one line, and COPY DSK2.A DSK1.B drops one more line, so doing MORE DSK1.B shows 6 lines. Also, a very small comment, the copy command shows the number of bytes copied in decimal, while the "more" command shows the number of bytes displayed in hex. Still, Foxshell is very useful for testing. For example the APND command is useful to test appending, which I haven't implemented yet. It now just acts as the copy command, as it doesn't seek to the end of the file. My todo list is getting shorter, the remaining things are: - a couple of DSR commands (FILES, and something to MOUNT a directory) - support seeking for writes for fixed length records - support append
  15. Thank you @TheBF, will definitely take a look! More test software is very welcome, especially if I can trouble you with questions I might have... I might just copy paste from TIPI DSR code the EA loader it embeds, that should enable me to load your code. Or just using E/A cartridge.
×
×
  • Create New...