Video

All those many years ago, when I did a lot of programming on "The Beeb", I was so contemptuous of writing games... I wanted to write serious software for serious purposes. The irony is that if I had have "descended" into the "flippant", "useless" world of games programming, It'd have stretched me much further and made me a much better programmer.

There is a much simpler scheme (at least in concept). JUST DON'T DO FRACTIONS AT ALL! How to do this & get reasonable accuracy? Up front, declare a small unit that is "smaller than max permitted calculation error" & do all calculations in integer quantities of that unit. In game, you may choose say 1/10000th (or maybe better 1/2^n) of the playing field's dimensions. There is no "fixed point" (unless you consider the one right of the LSB the point). For the money example, let the quantities be in pence. When units are dimensionless (such as angle), choose unit that is 1/(2^n) of a full rotation. You simply ignore all carries beyond the nth bit when doing that rotation math. This "retro math" should not be retro! For example in computer aided design, integer meth should be used. Floating point math is nothing but trouble. It is very important in CAD that tests for equality work (is the cursor EXACTLY on that "handle"? Is that line & arc "connected"?) Floating point causes quantities that can never be "equal" so the thing you just placed, you can never "grab" again because you can't get the cursor EXACTLY on it. There is also the famous problem of "leakage" in PC Paint app with the paint roller, because line endpoints don't exactly match up. Endpoints of arcs other than 0°/90°/180°270° can't be exactly on line endpoints, if they are specified by center location, radius, & start/end angles. The floating point "solution" is to add "slop" in the calculation (if abs(A - B) < some small number then...). The slop "is small enough unless it is too small". If I move something around in CAD workspace, its (X,Y,Z) parameters change in precision! And no, fixed point or integer math CAN & SHOULD be used for trajectory calculations! The problem with floating point is that it has resolution that differs with the distance from zero. If I put (0,0,0) at the center of the sun, what about when I am near Jupiter? Resolution & precision will degrade! Now I have a system with precision that depends upon where I choose (0,0,0). Floating point is for quick scientific calculations for those too lazy to properly scale their units.

The "boo-boop" of a BBC Micro being switched on fills me with such nostalgia.... so many "adventures" from my youth started with that sound.

APL?!

Programming a microcontroller in C? Disgusting! What's wrong with assembly language?! ;)

DrMattRegan did a fantastic set of videos on the details of most stages of CPU from a digital logic perspective.

The best way to learn such a profound question is make your own computer CPU. Not with commercial microprocessor like Z80, but with TTL gates or micro-programmable bit-slice chips like Am2900 series. Or in modern days, with FPGA chip and Verilog IC design tool. You can design completely new instruction set of very simple 8 bit CPU like 6502 and simulate it. Only with simple gates and macro blocks. No existing microprocessor is needed. Most tools are free and hardware evaluation board is not expensive. Recommend even for hobbyist.

This was s great overview.

If you want to understand why kids might use this lang, which is a very small crowd, look up "permacomputing".

It is entirely possible to write programs in BBC BASIC and never ever have to use goto.

Great work! I love your dry humor. Did you talk to Jeroen Venema?

In 1976 I bought the recommended calculator for my university physics class, an HP-25, and discovered RPN. In the 80s, i played with Forth for a while.

What CPU should be the first implemented in Graphene? The venerable 6502? z80? cray 1?

I would have taken a chronological approach, starting with an unpowered CPU. The power is applied to the circuit, a circuit external to the CPU holds the CPU RESET* pin low for a while to allow the power to stabilize and possibly some other circuit(s) to be set to a known state. When the RESET* pin is low, the CPU is stopped. Then the RESET* pin is set high. The CPU then fetches an instruction from memory (ROM) and executes it. The location of this memory address is hard-coded into the CPU chip and is part of the CPU documentation. The CPU then proceeds in the way you describe, fetching instruction after instruction. There can be variations such as the CPU loading other values from ROM before starting the instruction execuction stream.

It's often used (FreeBSD) in boot loaders where space is at a premium

I've had countless PCs and laptops over the years. I really which I'd kept my BBC computer, so easily interfaced, such a clever language. I hand disassembled the Basic ROMs, very tidy structure, I learned so much from it. Later, Pascal and Forth.

Some comercial games on the sprectrum were actually in basic, they were very good too all things considdred. Carnell Software Ltd IIRC did a couple.

I never liked BBC basic, Sinclair basic had already burrowed itself into my brain, and the single key keyword system meant I could enter code extremely quickly.

You stil skipped the explanation in this video too. You jumped directly to explain machine code and how to program machine code (assembly) and a mini routine. No! Your student actually asked "how the decoder works", the only answer is simple. IT IS JUST a mini ROM INSIDE the microprocessor like the z80 and any other processor!, THE fetched instruction is placed in its address bus, and the data stored in that mini rom activates multiples lines, one line can be enhable register B plus READ, it will dump the value in its internal data bus, and enable register A plus WRITE, and so on, that will make ld a,b , in one tick clock, if multistage instruction, a counter can count up the stage, the count also will be feed in the decoder mini ROM , AS THE LOWER addresses bits, that counter can be reset to stage zero, so, one of the bits store in the rom must mark when the instruction ends its execution. Now, the next question the student will ask is, how the ADDRESS DECODER of a ROM works. And the answer is , it is just a binary tree of AND / OR gates!. You can teach the basica of addressind decoder to enable the correct byte /word to be outlut from that mini rom

Used Pascal on a TRS-80 at college where they had a CP/M computer (used an Intel CPU) and Turbo-Pascal and Borland C at home.

South of France. November 12, 1983. My father handed me a black box "Sinclair ZX Spectrum" and said : "Open the box, read the book and have fun". 20 minutes later on the little B/W tv I saw a message : "(c) 1982 Sinclair Research Ltd.". Thanks dad!

Ah! The fun of dialing into my ISP at 28 kbps, downloading email on Outlook Express and using IE 5 with JavaScript and ActiveX fully enabled. No wonder my poor computer was always crashing and freezing...

Check Ben eaters video how the decode is executed

Great video 👍

Hey I just posted a video short of a Zilog I-box prototype from 1997. Really cool device my grandpa brought home for me. I had said I wished we could have internet on our TV and he smiled and said “we are working on that” and a few months later this thing came home. Lost it for decades.. just found. Let me know if you’d like more information or videos.

I played quake over 14.4 modem. Worked ok when we got it working. Good times!

The original engineers of the 'ball' mouse at Xerox Parc, quickly discovered the mice picked up dirt and grime from surfaces and started to give unwelcome results. One realised the benefits of IPA as a cleaner, so a technique developed of dunking the poorly mouse in a bucket of alcohol (lidded, we hope) After some time they learned that particular mice needed more frequent dunking, some eventually spending more time in bucket than in use, these were then declared 'alcoholic' and retired. ; )

Just getting into the 8 bit homebrew hobby. Watching these videos is a great way to learn hw these systems work. Hopefully I'll engineer one of my own one day

I can understand now after watching some of your videos why you teach, your delivery is so calm and non patronising.

ZX81 screen blanking only in fast mode, the ZX80 however screen blanked on key presses always. the '81 used an isr to drive the screen, the '80 did drove the screen with waiting for keypress.

I recently got back to my VIC-20 and started looking at FORTH. I think it's pretty awesome to have any kind of language other than BASIC V2 on the VIC.

You didn't have to write out asm on paper on a Spectrum if you got a copy of HiSoft Devpac. It had an assembler (called GENS - fully relocatable, fit in 6k) as well as a debugger called MONS that could single step and breakpoint (again the debugger was only a few k and fully relocatable). Given the Z80 has absolutely no hardware debugging support, it was quite a feat to make MONS work, especially using so little memory. That Spectrum +3 you have also has all RAM bank switching (so you can have the entire address space as RAM, it's how you can run CP/M on a +3). The BBC Micro also tokenizes its BASIC, if you hexdump a saved BBC BASIC file you'll see all the BASIC keywords have been converted to a single 8 bit value. BBC BASIC is one of the few BASIC interpreters (maybe the only one?) of its day to support local variables in named procedures. It was miles ahead of ZX BASIC (and light years ahead of the excuse for a BASIC interpreter that the Commodore 64 had). The other thing that really put the BBC Micro ahead back in the day is none of its memory was contended, in other words, the video circuitry never stole cycles to fetch data from memory, this thanks to the 6502 family having a very regular memory fetch patten (every other cycle) so the video circuitry had regular slots where it could fetch video data. Unfortunately the Z80's memory fetch cycles are very unpredictable so you can't do that on a Z80 based system, you have to allow the video circuitry to pre-empt the CPU for video ram fetches (hence lower RAM being contended on a Spectrum, and pages 4-7 on a 128k +3 being contended). The lack of contention on a BBC Micro made it very fast, the 2MHz BBC Micro was easily faster than the 3.5MHz Spectrum (in the hands of a good 6502 coder!) BBC BASIC is also quite fast, the Z80 versions also performed well. That's not to say Spectrum BASIC isn't a work of art (it is) as they essentially fit the interpreter and the Spectrum's rudimentary OS into one 16K ROM.

I have source files larger than 64k *targeting* machines with 64k of address space :-) Not hard to do given asm is less compact than its machine code equivalent.

Makes me think of the tiling engine used by Commander Keen. It writes tiles into EGA memory and uses the hardware to scroll around. The hardware can only scroll so far, so the game writes tiles to video memory just off the edge of where the screen is scrolling to, plus replacing tiles where sprites in the main screen were before drawing new sprites.

I was a little kid back then. I remember looking online for advice to beat Starfox for SNES and discovering lots of Japanese websites and a warez copy of Atlas V V6 JE and I discovered the world of animation and comicbooks abroad. In the later 1990's I also got into 2channel and SomethingAwful, the mother and father of 4chan respectively. I have very fond memories of oddities like htmlchat where you had to refresh the page manually, and making music in Dance eJay and later FruityLoops to share with friends, as well as modifying simple Sharp 68K games and sharing the mod images and things like that. This all came off a hand-me-down Amiga 1200, then later a Sharp X68000 a neighbour was getting rid of for homebrew stuff, and an Olivetti Xana 200 Windows 95 IBM Compatible which was my first "proper" computer, all of which I kept in my little cave working on stuff. It was really an incredibly special time -- not so much I think, because of how little there was, but how incredibly focused it was and how unjaded it was. We all had to be precious with our internet usage, and so shitposting and things like that were highly discouraged, and qualityposting was encouraged and basic nettique so you didn't waste the time of others. As a result, the internet was just, a very very high effort place to be, where everybody did their best and likewise, attention was also deeply maximized so it was very focused and personal, and as much time offline was spent into putting things online a relationship which I think has now changed. Just as I think, broadband removed the cost of entry (which is good), it also made shitposting prevalent by removing the material cost involved, but it also evidently meant that human-time still got wasted something we still haven't solved. Likewise, phones robbed people of the ability to have what I'd call a "symmetrical relationship" with the computer, where instead people get filtered into bad behaviours and dark patterns since constructing good complex answers now is practically discouraged because doing so is tedious and difficult and there's a kind of social prisoner's dilemma of if nobody else is doing it, why should you? Even shitposting, before phones still had that air of qualityposting. People took longer to think about what they were saying, and be cheeky and clever instead of just referencing things. Quantity has a quality of its own though, and that's the direction the internet has been moving in for a long time -- so none of us should be at all shocked that generative models are going to slush flood the internet with nonsense. We'll pretend it all happened at once, but really its been where the internet was slowly heading this entire time, isn't it? What comes with volumes of stuff I think is hidden messages, which would lead to radicalization and fringe pushing. I think shows like X-Files and Serial Experiments Lain got this on an unconscious level at least. You might want to give Lain a go, since its quite a surreal borderline horror series about a girl in the late 1990's early 2000's slowly losing her mind to conspiracy theories on the internet and getting lost in the weird ether of online mythos and cultism. e: I feel you will enjoy this song which captures the feeling czcams.com/video/QL1Dv_BGf18/video.html

I'm hoping that you go into the whole super mario bros biggest smoke and mirrors thing is that there is no level data as we would conceptualize it. The game works like a little assembly line that constructs the whole game world on top of a endless pre-formed void right before it's rendered to the graphics buffer. And that thinking about trying to go backwards in a level in SMB creates the absurd concept of how to run an assembly line in reverse.

Very interesting video. Remember when typing a BBC BASIC program to use the AUTO command. Also learning the command abbreviations also helps such as P. for PRINT and M. for MODE [of course on the Electron you could use the brilliant CAPS LK FUNC key to quickly enter commands]. VDU23 is also worth learning about. MODE 7 is a Teletext mode and can be used to create Teletext style block graphics - try two consecutive lines of P.CHR$(142);"HELLO" for enlarged text. PROC and FN can be used instead of GOTO and GOSUB to make a tidier program. ON GOTO and ON GOSUB can also be useful. REPEAT... UNTIL 0 is a better way of creating an infinite loop of commands.

I really enjoy your video, but it's way above my head. I would like to have a retro-CP/M prebuild, like a Phoenix256 or a Commander X16 or such. Also, I like to play around with BASIC hobby coding. If anyone here wants a fast line number style BASIC for a modern computer, PC-BASIC is a free download. It would run this code shown above very,very quickly.

pro tip: modern 3d engines also do not draw whole tilemaps offscreen. There's a culling stage where triangles that fall outside the render viewport are discarded.

hey i have a megafile 30 that doesnt work. when you turn it on it spins up but the activity led is CONSTANTLY on as soon as you flip the power switch. also it doesnt seem to do the selfcheck, the heads only "click" once shortly when it has reached operational rpm... the harddrive sat in our basement for like 30 years now. I cant find anything wrong on any of the boards they look brand new, I also reseated the harddrive connectors to the pcb and that didnt help. You think the heads are stuck? how could i solve that? Someone in the Atari forum wrote that you could try to give it a whack in the direction the heads should be moving, timed right when they already want to move?

I presume there is a reason why you aren't using the Agon's "hardware" sprites for your sprite.

hey James - another excellent video - nice work! you're right that using VDU 23,27,1... to copy an area of the screen to a bitmap will only work with 8-bit IDs - which is why there's also VDU 23,27,&21... which works with 16-bit IDs 😁 another thing - it is possible to only plot part of a bitmap. if you set a graphics viewport, then a bitmap plotted using PLOT &ED will only draw pixels within the viewport. (NB this isn't true if you use VDU 23,27,3 to draw bitmaps). just set a viewport to be just the column(s) revealed on the screen edge and then use your existing loop to plot the edge bitmaps - the underlying code in the VDP deals with the clipping and will give you a bit of a speed boost. you'd just need to remember to clear that viewport afterwards. (or use the multi-context API to swap between contexts and remove the need to set and clear the viewport, just have one context with that viewport set, and a different context for other things - it's a shorter command to change contexts 😉) for drawing things like this it can also be a good idea to switch to using pixel coordinates, rather than using OS coordinates. it makes dealing with the Agon's slightly wacky OS scaling somewhat easier. btw, if you're after more performance, vertical scrolling is much more efficient inside the VDP... and RGBA2222 format bitmap plotting in 64 colour modes is inherently the quickest... 😀

Great video. Thank you!

I get a kick out of your disdain for Mario.

Nice video :) I've written a game engine for the old Arduino UNO 8-bit (16Mhz, 8bit, no video or audio), which drives composite output at 50fps, with split/full screen scrolling, sprites and a tile-map background with a resolution of 256x256. I've converted a couple of arcade games, including the scrolling Scramble, and the ZX Spectrum game Manic Miner to run on it (that one was a challenge as the 32K of the Arduino had to run the 48K spectrum game :) ) In my case I don't have nearly enough memory for a frame-buffer, so generate each scanline on-the-fly (AKA "racing the beam") using ASM to ensure it's cycle-perfect to match the screen refresh. The Scramble game and other demos are on my channel (flickering is just due to recording the screen with my phone - in real life they're super smooth).

@learnagon points out that "In 14:50 you say 27, 3 and I see putch(23); putch(7); putch(3); putch(1); putch(1); is this a typo or should it be 27, 3?" The code is correct, I said the wrong words, even though I was reading them out 🤦‍♂

Enjoying this new video very much, thanks 🙏 🎉

In 64 bits; 2,646,693,125,139,304,345/842,468,587,426,513,207 Good for 37 decimal places. No need for floating point numbers. Use integer approximations.

355/113