Fixed. Thanks.

It is as simple as possible a set of file system APIs (with support for multiple levels of subdirectories) I could come up with: - using 8 bit indices in the file allocation table (FAT is one 256 byte block) - requiring only two external APIs (read a block of 256 bytes, write a block of 256 bytes) - while accepting that it was designed to support my tiny serial EEPROM (64K max), for now

Mine is in the mail. I'm first building a 6502 version and then later I plan to build the 6809 version (which is why I started working on a 6809 Assembly toolchain for Hopper).

Thanks. You could tell that I spotted that I was wrong mid-video. These clash with the 32K SRAM on our board. Easiest fix is to configure the heap to end at 0x4FFF for now for the BE6502. Corrected and tested: (PLD update is easy .. if we abandon 12K of RAM for 2 ports) github.com/sillycowvalley/Hopper/commit/6384669248ebc17fcef095abddf55e64f2445bcb

My 6502Retro ROM begins at C000 and ends at FFFF. When I make the ROM image for the SST27F512 flash, I concatenate each of the 16k images together and flash them all at once. So the assumption that ROM ends at FFFF is perfectly fine. 😊

:-) Oh, all right ...

Yeah, early Microsoft products (BASICs etc.) were developed using a PDP-10 (IIRC). They used a peculiar approach to build emulators for microcomputers: when running compiled i8080 or 6502 code, the system would raise "Unknown Instruction" interrupts, and the handler would look up a subroutine for that instruction, execute it and pass control back to the program, which would step to the next instruction… rinse & repeat. That allowed Allen and Gates to quickly build emulators for the new systems they targeted

:-)

No. I used the same PLD in my previous design too and it never got warm on that board either.

@@biggertigger Wonder what i could be doing wrong then. My design works peerfectly but the PLD gets pretty damn hot.

What's the part number of your PLD and what speed are you running the CPU at? Mine is the F22V10C-7PX (7ns propagation delay) and I'm running at 8MHz (125ns clock cycle period). The slowest 22V10C would be around 25ns propagation delay. Clock period for a 14MHz 6502 would be 71.4ns - at that point that's a significant chunk of the clock cycle being allocated to glue logic. I still think it shouldn't get warm (the negative effect should be unreliable behaviour). Another possible reason for heat could be overloading one of the output pins by trying to drive too much. Have you shared your schematic anywhere? I searched for generic overheating reasons for CPLDs. Maybe one of these triggers an idea of what's going wrong: - applying a higher voltage than specified can increase power consumption and heat generation - driving too many loads or driving outputs that require more current than the PLD is rated for can cause excessive current draw and heating - connecting too many inputs to a single output (high fan-out) can increase the load on the output driver, causing it to draw more current and generate more heat - if the internal logic of the PLD is poorly designed, it can lead to unintended oscillations, which can increase power consumption

@@biggertigger Thank you for being so incredibly helpful, it's difficult to find information about these old plds haha. The part im using is ATF22V10C-10PU. I don't have the schematic in digital form unfortunatley, but basically it's just simple glue logic, I'm using all the IN pins as adress input and the I/O pins as outputs. I run the system at 8mhz, same as you. The last thing you point out there might be the culprit. "if the internal logic of the PLD is poorly designed, it can lead to unintended oscillations, which can increase power consumption" But I looked at your PLD code and it's pretty similar to mine. I am however not using pin 1 as the input for the clock, the clock is connected to another IN pin. The output is connected to at most 5 CMOS inputs, which should be within spec. The system runs at 5V. When meassuring with a heat camera the PLD stays at a constant 50degrees celsius or 122degrees farenheit

Nice. 1.023 MHz version, I presume. Out of interest, can you share the C code? Here is my version: gist.github.com/sillycowvalley/37afedf1cb7105e70ad7b51ce7cb8105

@@biggertigger This is the version I have based my test on, just hammering it into C shape with printfs, [] and clock_t. It is a PAL C64 running at 0.985MHZ. Without badlines and at 1MHZ we would be at around 11.4 seconds.

That's pretty darn impressive!

@@biggertigger You made the perfect comment at the three minute mark. The extrem disparity of modern compilers and systems and the potential code size of the target system allow for an amount of optimization that would not be possible in a reasonable amount of code and time when compiling on and to systems of comparable power. Oscar64 can easily consume gigabytes of RAM when compiling larger cartridge based games.

Can you share the disassembly for your version of main() for Sieve?

I actually have one, just wasn't using it. My cloth ears can't hear the difference but I'm keen to learn more since the video part is clearly not one of my strengths. I just did some test recordings with it to see if I could hear the difference. Happy to be schooled on this .. already using the RNNNoise filter in OBS to remove my keyboard noise (on the advice of another viewer).

@@biggertigger Either that or get further back from your mic. It's picking up too much. Nice video though. I have videos up on my other channel, so I'm speaking from experience.

>I am a little curious why you left the Fibonacci implementation as recursive since it's so easy to write iterative. This is a deliberate test, usually fibo(24), to test both function call performance and that we have at least got reasonable stack depth capability. It was originally ported from MicroPython to benchmark the Hopper VM on RP2040 against MicroPython .. and then I found that it is also good test to check if we have a reasonable amount of stack depth .. For Hopper, I have a CHECKED build mode which does tons of stack limit checking and also checks that stack balance is as expected on exiting a function (SP same as it was on entry). I intend to add a CHECKED mode to Tigger C. Obviously it is not something you want in production code (and it also includes other checks like range checking on arrays, division by zero, etc)

@@biggertigger If you don't already, you should consider doing static checking in the compiler for obvious things. Loop conditions like `i <= U{TYPE}` should net a warning at least when you can't check the value and if they use a constant that matches U{TYPE}_MAX it should be an error.

Agreed. "for (byte i = 0; i < 256; i++)" is the common form of this mistake for Tigger C. Really should be caught at compile time. Another variant of this is "while (i > 0) { i--; }" for an unsigned type. Hopper currently catches neither of these ..

Yellow is the times or Hopper (which runs on a VM), orange Tigger C.

Couldn't agree more. :-)

I have a 6809 RetroShield on the shelf ... just started work on a 6809 toolchain for Hopper ...

Thanks. Well spotted. Had a problem with $00FF (probably because the Hopper 6502 Assembler saw it a $FF which would make it the zero page version of the instruction where adding X wraps back into the zero page). However, even $00FF, X is suboptimal because it causes the crossing of a page boundary (+1 cycle). So, the eventual implementation of your idea was put the offset of the MSB in X instead. Here's your DEX-less / INX-less version without the zero page wrap or extra page boundary cycle cost: // POPL [BP+0x00] // POP [0x01FF - BP -0] (16 bit) LDA ZP.BP SEC SBC # 0x01 TAX PLA STA 0x0100, X // MSB PLA STA 0x0101, X // LSB Or: // INCLI [BP+0x00] # 0x0001 LDA ZP.BP SEC SBC # 0x01 TAX INC 0x0101, X // LSB if (Z) { INC 0x0100, X // MSB } (and yes, the premble in these two cases should be LDX ZP.BP followed by DEX - this is what the code looks like between peephole optimizer and whole program optimizer)

@@biggertigger I believe you were mentioning something similar in the video so I may be repeating you…. 😀 But a further optimization here would be, for value of 1, to replace the SEC SBC #$01 By TAX DEX ;)

Yes. See the note at the end of my (long) reply above. Here's an invite link to the Hopper Discord server if you are interested in further optimizations ... :-) discord.gg/H8cVAvhK

@@biggertigger The main problem is the code representation on which you try to perform the optimizations. A stack based evaluation hides most interdependencies - you notice this in your video at around the 29 minute mark. Since the 70s compilers use intermediate representations that expose the dataflow, which culimated into SSA in the late 80s. The other problem is the low level at which you start optimizing. Compilers usually go through several levels of lowering from AST over SSAs with various levels of IL, and finally assembler with basic blocks. Each of these levels provide inside and optimization opportunities for the compiler, that cannot be done by later stages. So your compiler may benefit a lot, if you try to go with a more dataflow virtual register representation before the actual assembler.

Excellent suggestion. Thanks. Globals can now at a configurable location (any starting point and range in the zero page is an option, or just somewhere else in memory). I added call graph analysis (required lightweight first pass) and now I allocate most locals statically in the same location as the globals. With this, and other improvements, the Sieve benchmark is already running > 2x faster than in this video (2.3 seconds).

First time I've heard someone actually think 6502 is C friendly but I respect this perspective! If your whole program's live local variable footprint fits in 256 bytes you can manage okay but if not things could get tough. Not sure what the best strategy is then, maybe relocation? I don't think MOS made the wrong choice but if they found a way to fit a 16-bit SP or zero-page relocation thst may have been a game changer. Then again 6809 wasn't really ever that big so who knows.

I've moved on from benchmarks to use Tigger C to implement something useful: a little file system for the serial EEPROM on my 6502 SBC that runs the Hopper Runtime (virtual machine). Since Tigger C emits my Hopper 6502 Assembly syntax, I'll easily be able to prototype in C and then integrate the resulting assembly into the Hopper Runtime (which is all 6502 assembly). This exercise should prove one way or the other if Tigger C is actually good for anything in the real world ...

@@espfusion A stack is only one way to implement the calling semantic of C. Most real world programs that you want to run on these machines are not recursive, and thus local variables can be assigned to a "static" stack using call graph analysis. I have spent almost three years now implementing a C++ compiler for the 6502 (Oscar64) - and given the limitation of the potential programs that may be developed for the platform the CPU is an excellent design for a high level language target.

@@DrMortalWombat Understood, it's a good strategy. Still, even just storing the maximum live variable depth you're probably going to run out of zero page space pretty quickly, especially with competition from global/static variables and other housekeeping needed in zero page. You can start allocating the rest by absolute addressing but you'd still need pointers to be somewhere zero page at least temporarily, so I wonder if it's not usually better to just start spilling the oldest variables to and from absolute space in big blocks and writing the new stuff there... Also, while I do expect actual loop recursion isn't that common (and pretty easily specially cased) it's probably a lot more common to see the same functions appear at multiple sites in a call trace. I assume this would be handled at least to a point by aliasing the function into multiple versions but that becomes a bit of a code bloat problem.

Exactly. The 6502 shares its small instruction set and minimal cycles per instruction with later RISC processors. It's clear that the engineers at Acorn drew inspiration from the 6502 (used in their Atom and BBC Micro computers), influencing their design philosophy for the first ARM processors. Creating benchmarks where the 8086 excels would be straightforward: just perform multiplication or division using the MUL and DIV instructions, or leverage string-specific instructions like SCAS and CMPS. I'm pretty sure the Mandelbrot demo / benchmark would be way faster on an 8086 (thanks to IMUL and IDIV).

@@biggertigger yeah, I very conveniently failed to acknowledge the superior alu in the later processors. LoL. I should be in marketing.

​​@@biggertiggerboth at the same clock speed I'm not sure. The MUL and DIV operations aren't very efficient. They helped reduce memory operations which back in the day did help the 8088 and 8086 make up for their lack of bandwidth and win out on multiplication and division but back then we were comparing ≈1mhz 6502s to ≈5mhz 8088/8086s, and in most other cases we thought of them being roughly equivalent. Both at 8mhz would see what? The 6502 at 8MiB/s, the 8086 at 4MiB/s, and the 8088 at 2MiB/s. I'm not sure even the native 16bit ALU could make up for that. Edit: this is me being curious rather than argumentative btw. I was more of a 68k weenie anyway 😋

It's not really a fair comparison because the 6502 basically needs 4-8x faster memory. At 8MHz in the early 80s you're probably already limited to SRAM. Hence why you didn't see > 4MHz 65xx until you got cards with small SRAM caches.

@@espfusion I've already got it running about 2x as fast as it was a week ago (2.2 seconds for the Sieve benchmark compared to 4.5 seconds in this video). Even after multiplying that by 8 to make up for my 8MHz clock, that's faster than anything on 6502 from the BYTE magazine article other than a pure assembly solution. Most of the speed improvment came from implementing a suggestion from @DrMortalWombat to use simple call graph analysis to determine which locals to use static storage for (zero page of course). The compiler uses what is available and then overflows into regular memory (which is still faster than BP+offset stack storage). With the exception of the Fibonacci sample, all local variables can be static. Arguments are still on the stack (obviously). One massive advantage we have over the gods of the 70's, like Woz for example, is our completely overkill development platforms. Back then it was mostly self-hosted which is incredibly impressive. So much easier for me to just focus on the outcome without worrying about how efficient the tools are.

See my reply on GitHub, or: discord.gg/QmZ68cmQ

Yes, my previous board last year used the MAX232 as per Ben Eater's design: www.hackster.io/michael-cartwright/rs232-using-the-motorola-6850-acia-with-a-6502-computer-33ea36 It seems kinda silly to convert from TTL to RS232 and then back again so this time I just went direct to FTDI. Current version with schematic can be found here: github.com/sillycowvalley/Hopper/tree/main/Source/Projects/6502SBC/EasyEDA/6502%20Machine/rev12

@@biggertigger Not a Max you dont need it. that is a voltage pump. As you would know. We really only need 0 and 5 volts. no Minus or 25+ stuff that was way back in the day when they had looooooong cables and they needed it. Today we use things like arduino and they just use 0 5 volt serial perfectly fine.

@@biggertiggerThat makes more sense to me as well. Ben Eater I am not sure why he would want to do that old rs323 as only older gear will be able to use it. I am glad you are working on Hopper cross platform. I am very quickly running out of love for the 65uino. If your very skilled with assembly and such I feel it would be great for you, but I am a newbie and I feel Anders great patience will run out very soon with me

I really like the look of hooper. I would love to check it out. I am getting a very basic Ben Eater PCB soon I hope. and I will be just doing newbie asm stuff with it, no trying to load code into ram.

I've been dabbling with a cross-platform version of the desktop runtime using Terminal.Gui (with .NET Core). I like this approach since it could give me a single version to maintain for Windows, macOS and Linux. If there is interest in that sort of solution, I'll continue with that project.

@@biggertigger That is great, as linux has a lot of tools to use. cross platform would be super nice.

That's what I believed too .. until I tested GPT 4. It excels at the boiler-plate / boring stuff. For example, generating documentation. Take a look at this page. It was entirely generated by GPT (zero edits, modifications or formatting by me : I just gave it the source code for my HopperFORTH and asked it to generate reference and user documentation). It may be a bit boring but it is a hell of a lot better than the documentation I would have written (nothing): github.com/sillycowvalley/Hopper/tree/main/Source/Languages/FORTH

I've added some references to the source from the Teensy site (for SD and timers/alarms). The problem I'm having now is a conflict between the generic/Teensy SDFat library and the RP2040 library : it is a bit annoying that you don't seem to be able to keep them both installed at the same time.

@@biggertigger Maybe I'll run into the same conflict with RP2040 when I get around to integrating it. Between ESP32 and Teensy I get warnings about multiple SD libraries but it seems to resolve. Maybe you can temporarily rename libraries to resolve the conflict. Maintenance nightmare though.

Sounds interesting. In C, I assume? I'd love to port it to Hopper as a demo on the RP2040 when you are ready with it. Here's an invite to the Hopper Discord server if you want to discuss: discord.gg/xbskyHGG

@biggertigger getting an error saying the link is invalid

@@instatemp They expire after a while. Here's a fresh one: discord.gg/D5qf4fHr

The SSD1306 OLED is essentially a matrix of monochrome pixels (it only has 'graphics mode'). My sprite engine works in 4x4 pixel cells because it is designed to minimize memory use on the CPU side : to have a memory map of the entire matrix of pixels would take 1K. The 65uino only has 128 bytes total. I keep track of my sprites rather than the entire display to make this possible. When running on my 6502 SBC we have 32K of RAM available so this is a non-issue (and the Hopper library keeps a 1K buffer for this screen and supports graphics and text APIs similar to the AdaFruit APIs for MCUs, but on the 6502).

Yes, there is room for a revision by someone that isn't a software guy. ;-) (the top layer is indeed filled (GND))

You mean like a minor zig-zag and just regular thru-plated holes?

@@biggertigger exactly!

Indeed. 'uses' and units are absolutely inspired by Turbo Pascal. My favourite time spent with Turbo Pascal was circa v4, just before objects were introduced. In Turbo Pascal they were a necessity to provide separate compilation units but the same structure still allows you to live without project files, a 'make' utility, etc. And then there are the obvious benefits (like encapsulation).

I have two Neo6502's and I'd appreciate a little help getting from zero to WozMon using the Arduino IDE. After that, I'd be able to get my 6502 runtime working on it. Need to simulate RAM, ROM and an ACIA (prefer 6850)

discord.com/invite/wsR6vBDC

All the source for the different runtimes is on GitHub. A good starting point for a Linux port would be the C version of the Portable Runtime that I use to get the VM onto Arduino-style device (like the RP2040 boards). This version of the runtime is machine translated from Hopper to C (easy to update as the runtime evolves in future). To get a client runtime working (to support a first class GUI development environment including editor and debugger) you need very little from the host operating system: - 2x keyboard APIs (IsAvailable and ReadKey) (mouse interface is done as 'special' keyboard events) - 6x screen APIs (Columns, Rows, SetXY(col, row), Print(char)) - one font, foreground and background colours for text cells - access to the file system (Arduino version is close to the usual C / Linux file APIs) - 5x COM port APIs (Connect, Close, IsAvailable, ReadChar, WriteChar) That's it. Getting a blinking text cursor can be dealt with later .. Interested in taking on the project? Here is an invite to the Hopper Discord server: discord.gg/v9p8rDPk

@@biggertigger thanks for your work and the answer ... i will discover these C Area .. ok ...