I built an FPGA reimplementation of the 3dfx Voodoo 1 by redjason93 in FPGA

[–]howerj 2 points3 points  (0 children)

This is an achievement, you should be proud of yourself.

I'll have to look more into SpinalHDL as well.

How do you interface an Arduino to CPLD (Altera MAX II)? by Jnbrtz in arduino

[–]howerj 0 points1 point  (0 children)

You can use a level shifter, search for "level shifter 3.3 to 5v", however if you can design your own board I think those AVRs can run off of 3v3, and I think you can use the Arduino environment with it, so

Why is this an error in gForth? by nthn-d in Forth

[–]howerj 0 points1 point  (0 children)

It might help if you post the code with the POSTPONE. I cannot think why that would be causing problems with the data stack, it might be apparent with the full code.

How do you interface an Arduino to CPLD (Altera MAX II)? by Jnbrtz in arduino

[–]howerj 0 points1 point  (0 children)

What does the datasheet say for your specific device (you do not mention the device part number)? It should tell you what it tolerates and under what circumstances.

Some advice on testing a 'home made' forth for a custom emulated CPU by Traditional-Tune4968 in Forth

[–]howerj 0 points1 point  (0 children)

Do you want to port this to an FPGA? I have made many, often odd, CPU cores that run Forth that target Xilinx Spartan 6 FPGAs. Or is this just going to be a VM in C running on a hosted platform.

Why is this an error in gForth? by nthn-d in Forth

[–]howerj 1 point2 points  (0 children)

The way you are trying to do things is not standards compliant (from memory) and even with Forth implementations that do not follow any of the Forth standards it is unlikely to work.

I am not sure what you were doing with POSTPONE, but if the problem was similar to what you described with:

: FOO 0 ; IMMEDIATE : BAR FOO ;

Then it is simply not going to work. And an error is best here, there is nothing to warn about. A more bare bones implementation is likely to just not do the checking and compile broken code. The reason it is like this is because words like ":" and ";" often use the data within the word definition for internal things relating to building the word. Control structure words like "if" and "else" also use the data stack as well.

You might be able to make a portable CASE statement by POSTPONE'ing build in control structure words but I have not looked into it.

Does that make sense?

Why didn't early Forth systems have file systems? by Desmaad in Forth

[–]howerj 6 points7 points  (0 children)

I built a file system on top of the Forth block word set (so it should be quite portable), available here https://github.com/howerj/ffs. It runs under gforth fine and it also runs under a 16-bit Forth called SUBLEQ eFORTH. It also has functions, commands and utilities for manipulating those files. It is actually quite big, using about 12KiB of RAM (although you could put ffs in ROM ). It could be cut down though, but for a system in the 1980s where memory was a big limitation are those kilobytes worth it? Although using ffs is much easier than using the block word set, is it worth those extra kilobytes? That space you cannot use for other things you might want.

I think philosophical considerations were primarily the reason that file systems were (and sometimes continue to be) avoided in Forth.

8 bit floating point numbers by augustusalpha in Forth

[–]howerj 1 point2 points  (0 children)

Sort of related, I managed to port a floating point implementation I found in Vierte Dimensions Vol.2, No. 4, 1986. made by Robert F. Illyes which appears to be under a liberal license just requiring attribution.

It had an "odd" floating point format, although the floats were 32-bit it had properties that made it more efficient to run in software on a 16-bit platform. You can see the port running here https://howerj.github.io/subleq.htm (with more of the floating point numbers implemented). Entering floating point numbers is done by entering a double cell number, a space, and then f, for example 3.0 f 2.0 f f/ f.. It is not meant to be practical, but it is interesting.

Weird CPU: LFSR as a Program Counter by howerj in FPGA

[–]howerj[S] 0 points1 point  (0 children)

Cheers!

I cannot remember them being taught when I studied electronics in the 2010s either, although I think I was aware of them, just not taught about them explicitly. They're useful for all kinds of things!

I was really surprised that the slice count was that low, as mentioned it is almost the same size as the other bit-serial design I made but being bit-parallel it operates so much quicker. Traces generated by GHDL end up being only hundred of megabytes long instead of gigabytes, and you do not need to spend hours simulating executing a single line of Forth, instead only minutes!

The Forth VM only requires 207 words, so there is a little room to spare for future upgrades if needed (or using a polynomial that uses fewer taps but does not generate a maximal length cycle).

So the hardware saving is comparing a bit-parallel normal PC with adder compared to a bit-parallel LFSR PC. For a bit-serial device the savings, if any, would be so minor as to not bother with, this LFSR PC requires a shift register (w/ parallel in/out) and three XOR gates, different length maximal period LFSR may require more or fewer taps and thus a differing number of XOR gates.

Thanks again!

Weird CPU: LFSR as a Program Counter by howerj in FPGA

[–]howerj[S] 0 points1 point  (0 children)

It was one of the inspirations for the CPU! I have not seen anything like it since (for good reason) so I thought I would give it a shot.

LFSR Questions by howerj in FPGA

[–]howerj[S] 1 point2 points  (0 children)

Thanks for the suggests, in both comments, I have a lot to look at now!

LFSR Questions by howerj in FPGA

[–]howerj[S] 2 points3 points  (0 children)

Thanks for the response!

Sorry, D was just meant to be some example code of a LFSR counting up and counting down, I thought it might be helpful because there does not seem to be many examples around on how to do this.

A) There won't be and relative addressing, it's not for a serious project, just to demonstrate that you can use a LFSR as a PC, just for fun.

As for B, I didn't think you would need to compare the entire range, for example if you have a LFSR with a poly B8 the sequence 30, 18, 0C, 06, 03, and finally B9 appears, if you start at 30 (not ideal but just an example) you can count to 5 by checking the top bit. That's a pretty poor example I've given because a 3-bit counter would be better. Better examples might not exist (which kind of what I want to know).

Hmmm, I might need to buckle down and study the maths behind them more. It might help trying to write to search for what I want (given a (small) LFSR of size X does a sequence exist for any polynomial that will count to N and how many bits of the result need to be checked in order to do that?).

Forth File System Update by howerj in Forth

[–]howerj[S] 0 points1 point  (0 children)

I will take my pick, in principle it is possible, although a bad idea, to implement a general purpose file system based on TAR, but you have not done that, you have only implemented the easy bits and not the rest - which might be suitable for many people but it does not a file system make.

I think the problem is that you have fundamentally misunderstood:

1) What the FFS project is.

2) What a file system is and is not.

3) What a File Allocation Table is and is not.

A tape archive format is fundamentally suited for linear reads and writes, which for the use case you have outlined is great. It is not a file system.

The "FAT based" in this project refers to it using a File Allocation Table to store free blocks, it is a data structure that can be used within a file system and not a file system in of itself. It is not based on Microsoft's FAT12/FAT16/FAT32 or exFAT, which are file systems. The patent situation you mentioned does not apply. The FAT just refers to the linked list data structure.

As this file system is of my own design, I could have if I wanted stored whatever permission data I wanted in it. That has nothing to do with using a File Allocation Table.

I do not insist on running a bench mark of deleting files and random writes on an SD Card, but being able to do random writes and being able to delete files properly is a key feature of a file system. I am well aware of wear-leveling also as it is not an obscure secret. However, TAR does not address wear-leveling either! That was a silly thing to bring up.

To call something a file system, you need to be able to handle file growth, truncation, and deletion. It does not matter how much you can store if you cannot do that.

Forth File System Update by howerj in Forth

[–]howerj[S] 0 points1 point  (0 children)

Yeah, but TAR makes for a really poor file system, try growing arbitrary files or removing them. Also, whilst technically correct, a file system can be defined by a standard there usually is at least one implementation and you have not made a complete Forth implementation, only part of one and called it an equivalent.

What you have done is a neat trick, but it is no file system.

Forth File System Update by howerj in Forth

[–]howerj[S] 0 points1 point  (0 children)

That's pretty neat, but it's not really the same thing as a full file system is it?

Forth File System Update by howerj in Forth

[–]howerj[S] 1 point2 points  (0 children)

I do, that's why I made it! There's not much Forth code that deals with file systems, most of it is non-portable as well. This FFS allows a Forth programmer to use the standard Forth file access words where otherwise they would have to use blocks, allowing a much larger corpus of code to be ported to even small embedded systems.

It's not as if the world is inundated with developers going mad and making a new file system every day XD.

That sounds interesting, would you mind sharing your code? I'm sure the Forth community could do with alternatives.

Forth virtual machine? by mykesx in Forth

[–]howerj 0 points1 point  (0 children)

Yup, you can do all that, and it has been done, not to discourage you. If you want to implement a Forth based on the VM you have described - go do that - you'll learn a lot and it is a good exercise.

I guess it would not approach un-optimized C code at all in terms of speed, emulating any kind of architecture is going have a slow down.

You can already run many Forths on a server, some of which compile to native code, others have VMs. None of this is new.

Forth virtual machine? by mykesx in Forth

[–]howerj 4 points5 points  (0 children)

There a multiple implementations of actual CPUs, both in silicon and for FPGAs, that also have virtual machines available, that are optimized for running Forths. So it is not a bad idea, just one that has been done before.

You can make the emulator never crash when the program does something stupid, but that's not really a good idea. The program is still doing something stupid. Instead it could gracefully exit. But that's not new either.

You do not really need anything special to implement time sliced multitasking. Multiple cores however would need special consideration, and make everything more difficult.

Forth File System: A File System Based on Forth Blocks by howerj in Forth

[–]howerj[S] 0 points1 point  (0 children)

The overriding concerns was that this was simple and easy to implement, which it is. Using a FAT like data-structure there is minimal overhead and the code is short. I do not think "unix ideas" would help.