Show HN: 1.5kb Microkernel for Ben Eater's 6502 Computer
github.comI'm actually more excited to see a new Ben Eater video on youtube than anything else.
His stuff is just fantastic. Even though it's lower level than I've ever worked, it's extremely entertaining and educational.
His 6502 series is just great, but I want to highlight another couple of videos he did:
"Let's build a circuit that displays an image on a VGA monitor! In this video, I talk about how VGA signals work and build a circuit that provides the correct timing of sync signals so that a monitor recognizes the signal."
His video series was very enlightening. Seeing absolute lowest level how that stuff is done is a wonderful insight into why stuff is the way it is today.
Thanks for posting. That‘s wonderful.
Skimming through this, this is the first piece of code that my eyes drilled into more deeply:
LCD__clear_video_ram:
pha ; preserve A via stack
tya ; same for Y
pha
ldy #$20 ; set index to 32
.loop:
lda #$20 ; set character to 'space'
sta VIDEO_RAM,Y ; clean video ram
dey ; decrease index
bne .loop ; are we done? no, repea
sta VIDEO_RAM ; yes, write zero'th location manually
pla ; restore Y
tay
pla ; restore A
rts
Since Y starts at a hard-coded value that is (well) below $80, this could use "bpl .loop" and drop the "sta VIDEO_RAM" special case.
In .select_option, I'd looking into doing a jump table. Ideas here: https://wiki.nesdev.com/w/index.php/Jump_table
You are more than right. This is just my first assembly project in 20 years, put together from scratch in a couple of days. Therefor I am more than greatful for every constructive hint, that helps me improve. Thanks!
You probably know, but it also would help readability and portability if you created separate constants SPACE and SCREENSIZE (or similar)
Also, if you want to go for idiomatic 6502 code, rather than readability:
- you want to optimize for size and speed by looping down from C to zero (rather than looping up from zero to C) where possible (because you don’t need to do a CMP to compare with zero)
- LCD__print wastes memory and CPU cycles. It can fall-through to LCD__print_with_offset, and that could fall-through to LCD_render,
Get qkumba or John Brooks on the Apple2Infinitum Slack interested, and you're likely to suddenly get a whole lot more optimized :-)
I've been writing to 65816 lately, so it may be that they're extended mode instructions. But does the 6502 not have PHX and PHY?
The 65C02 does (as well as AFAIK the 6510) if one compiles VASM with the according flags. Ben decided not to do so, neither did I for the feeling of good old times. Why make it easy ;)
The 6510 is what’s in the C64 - PHX and PHY definitely aren’t supported there (source: I was programmer on multiple published games, back in the day).
The NES is similar family too, and doesn’t have those opcodes - but the Atari Lynx has them (being 65C02).
Semi-related, I've been enjoying Robert Baruch's videos[1] on creating a FPGA implementation of the 6800, using nMigen and formal verification. First videos are almost like live coding, then he skips to a more compact format.
As a regular programmer, it's quite interesting to get into how the bits actually end up getting the work done.
[1]: https://www.youtube.com/watch?v=85ZCTuekjGA&list=PLEeZWGE3Pw...
Watching Ben Eater's videos renewed my interest in making some simple computers out of old hardware, mainly because the older hardware is simple enough that you can work with it on a breadboard.
The interest eventually morphed into doing something with all of the old parts I've hoarded. Going through the bins of parts, I've found things like 8051 microcontrollers (P80C550) and UARTs (AM85C30) and some old RTC units (MC146818). I ended up picking up a few 68010's (among other things) off of eBay with the hope of building a breadboard Linux computer, as slow as that may be. I believe the 68010 may be the only CPU in a DIP package still supported in some capacity by Linux (as long as you provide an MMU).
Hopefully this will actually get me back into writing/making videos about my projects.
I love, love, love Ben's videos, and this is an awesome project.
But to be as painfully pedantic as possible: can we please use the word 'monitor', here? Calling it a 'microkernel' really gives one the wrong initial impression.
Still, very neat. Now write a BASIC!
> Now write a BASIC!
No doubt an educational project. However, all the versions of Microsoft 6502 BASIC were collected and annotated by a Michael Steil in 2008.
Thanks for sharing this! I learned how to write floating point math routines from scratch by disassembling the ROMs on my PET and figuring out how they worked.
Nice to see the coefficients for the taylor series computation for sin() in the POLY_SIN table.
What does "monitor" mean in this context? Makes me think of either a display or https://en.wikipedia.org/wiki/Monitor_(synchronization) .
I learnt assembly language programming on a Vic20 in 1983, using this Vicmon machine code monitor:
http://commodore.software/downloads/download/211-application...
I like this explanation of "monitor", from https://www.atarimagazines.com/creative/v9n12/272_A_monitor_...
"The novice machine language programmer often does not have an assembler. Without an assembler, the programmer must assemble the program by hand, and then enter it by hand. Even a small program could require hundreds of POKEs followed by hundreds of PEEKs to verify that everything has been entered correctly.
A good monitor gets around these problems. It allows the programmer to examine memory locations sequentially. As each location is examined, the operator has the option of changing it or looking at the next one. A good monitor program also allows the operator to list a range of memory all at once. A third monitor feature allows the operator to move a range of memory to a new location in the computer. A final feature in a good monitor is the ability to execute and return from a machine language program."
It's this one: https://en.wikipedia.org/wiki/Machine_code_monitor
I seem to recall from my C64 days that "monitor" was a term for a type of utility program that would let you view memory contents and load data into memory. That seems to be similar to what this project is doing.
Monitor was the name given to lighweight OSes back in the day.
I think this explanation works quite well: https://www.c64-wiki.com/wiki/Machine_Code_Monitor
Learning about multiple wonderful things at once here. This is pretty much catnip for 6502 fans.
Are there any good resources for learning electronics for someone with a strong programming background and understand digital logic? Ben Eater videos assume knowledge of electronics and would like to know more
I found “Digital Computer Electronics” by Malvino and Brown really helpful. It starts from scratch. Was also a recommendation from Ben Eater, but you will only find used copies, since the book is not in print no more.
Don Lancaster's TTL Cookbook and CMOS Cookbook would be good companions for the Ben Eater series.
https://www.amazon.com/gp/product/0672210355/ref=dbs_a_def_r...
https://www.amazon.com/gp/product/0750699434/ref=dbs_a_def_r...
Actually both books are available from Lancaster's website as a free PDF:
Can't go wrong with the art of electronics. Not quite a classical textbook but also not a cookbook - takes you from basic theory to analogue to digital to computers etc.
There's not much to it at a basic level - theory wise, you need Ohm's law, Kirchhoff's Voltage/Current Laws, a few theorems (Then you add knowledge of active components, obviously)
N.B. Understanding complex numbers is a big help.
This reminds me of C64 tape loaders or "turboa" that need to load the program to RAM.
https://www.atarimagazines.com/compute/issue57/turbotape.htm...
Also let's not forget Bill Gates's 17 bytes loader
https://hackaday.com/2017/03/24/doing-it-with-fewer-bytes-th...
Anyone else remember the PET Rabbit [1]?
"Load, Save, Verify, Execute 8 K in 38 seconds versus PETs 2 Minute 45 seconds, plus more!"
There was a newer version that I had which was called the ROM Rabbit vs. this version that you had to load and save each time.
[1] http://archive.6502.org/publications/pet_paper/pet_paper_v3_...
Nice! my 6502 kit arrived today! And there is snow in the forecast this weekend- Really looking forward to building this.
Post pics, if you make a bending unit[0]
[0] https://futurama.fandom.com/wiki/Bender_Bending_Rodríguez
I just read your source code a bit, and there are a lot of things wrong. First, you should ALWAYS clear the carry when using ADC or set the carry when using SBC
For example: .increase: adc #1 sta POSITION_MENU
I have no idea if you increment or add two, since the carry is not cleared.
clc
lda CURRENT_RAM_ADDRESS_L
adc #$01
sta CURRENT_RAM_ADDRESS_L
lda CURRENT_RAM_ADDRESS_H
adc #$00
sta CURRENT_RAM_ADDRESS_H
ldy POSITION_CURSOR
cpy #0 lda POSITION_CURSOR cmp #0 cmp #0 is useless
jsr / rts can be replaced by jmp
clear_ram is super slow
There's a kinder way to share this. Ben's teaching a number of things here (basic electronics, computer architecture, assembly..) in an incredibly inviting and rewarding way. I'm confident he's reaching people at varying skill levels. Let's keep that energy going.
great job.