Thanks for creating this excellent addition to the workbench: www.imania.dk/samlesaet-hobbyelektronik-og-ic-er-abn-6502-single-cycle-board.htm

I have not. My Hopper runtime project is in the Arduino IDE. Is there a way to compile for RISC V from Arduino IDE?

@@biggertigger kzbin.info/www/bejne/lYCWcpivq5d8gq8si=gMrdPNMShKfuwgzh explains some of the compiler tricks.

Correct. I misspoke: unused inputs should be pulled up. Anders describes this part far better than I did: kzbin.info/www/bejne/rV6Un59ortJshq8

@@biggertigger It's a nice little board. I really should cobble together one some day. But it was many many years since I actually built anything with a 6502 so.... But maybe it could be adapted to a 6802/6809 SYNC and HALT signals as well - I'm a bit keen of building a small trainer board with one of those.

Well spotted on VPA / pin 1. I'll make a note in the description.

Shadow RAM is used for resolving slow ROM issues (i.e. ROM data loaded into RAM, before use). That, however need to have runtime frequency switching with C64-like memory banking. Alternative is system controller, which would preload ROM-data before CPU startup.

My Hopper 6502 Assembler is bit limited when it comes to positioning of the output : only the upper 8K or 16K of the address space for ROM in these cases. That said, it always puts constants at the start address of the ROM. Currently I have a 'reserve' directive for when I/O space may overlap with the ROM. During code generation 'reserve' emits NOPs for the I/O space but I have only made it aware of overlapping with method code and not constants (so far). For this reason, I put the IO space at 0xF000 (rather than 0xE000 where the constants are) for the 8K ROM (and I just leave it there for the 16K version so that I don't have to change the DIP switch settings).

More about the WD replacements: "The W65C21N is plug replacement of NMOS and CMOS 6521 and 6821 devices with current limiting resistors" "The W65C21S is lower power, faster and direct drive outputs with no current limiting resistors." The "latch" difference between ports A and B is described on page 17 better than I could ever hope to explain (when reading port A, you get the values from the lines irrespective of which are outputs and which are inputs, when reading from B, you 'correctly'' get the values for pins set to outputs from ORB when reading all pins - a peculiar difference indeed). www.westerndesigncenter.com/wdc/documentation/w65c21.pdf

@@biggertigger An interesting difference, which seems intent on correcting a potential situation with the original MC6821 PIA. In the original 6821 PIA case, reading the value of an Output pin on Port B could potentially return a different value than the Output register bit, in the case where the port Pin is excessively loaded, pulling it low (or excessively pulled high). i.e. The read value of an Output pin is always the immediate value on the port Pin! Mind you, I've never seen this as an issue, as typically I'm only interested in reading an Input pin value, and as such I would typically only test the relevant Input bit, and not make any assumptions about the read value of Port pins programmed as Outputs. Good to know about this difference though! 🤓

Discord invite: discord.gg/rrNWFXBE

You upload Hopper programs using Hopper Mon (from Windows) and the last program uploaded is stored in the I2C serial EEPROM. It is run automatically on reset (much like an Ardunino). It is possible to support Ben Eater's memory map (I/O addresses) by reprogramming the CPLD.

@@biggertigger Thank you so much! My boards should be here in a couple of days, but my son wants to build one too so I need to buy 2 sets of ICs lol. I have a Corsham Kim Clone, but I am so busy it's hard to find time to get it out and set everything up. I can have the Hopper board sitting out next to the computer and plug it in when I get a free moment. It's also small so it would travel well on vacations. I'm familiar with programing on an Arduino so this is really cool!

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

My understanding is that the early Atari's were developed on the Cromenco minicomputer

@@MichaelRBrown-lh6kn quite possible since it's impossible to develop anything on a machine with 128 bytes of RAM =)

:-)

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.