Subscribed! Brings back memories of writing assembler for the first time when I was about 10. I was 7 when I had my first computer, the BBC B in early 1982. It started a fascination and deep love of electronics and computing that continues today.
Very nice story that bring back a lot of memories :o) A trick I'm using when I need to time vertical blanking interrupt code is to change the border or background color at the beginning and end of my routine. That allows to visually see where the beam is during execution (ideally it starts just under the display area in the bottom and finish just before the top of the same display area).
Super interesting, would be great to see a video explaining some of the software you were using on the pc, and the general process, the bbc is an amazing piece of tech. Looking forward to your game release lol
I learnt all my BBC hardware knowledge from the Advanced User Guide. The vsync starts the vertical retrace, which is where the raster beam goes back to the top and takes about 5 character rows (this is an educated guess). By default, this is at the 34th character row when 32 rows are displayed and a frame is 39 long. If you really want to see some chasing the beam on the BBC Micro, take a look at my Frogger game :)
Amazing! I spent my childhood trying (and failing) to write games for the BBC but the sprites were always slow and flickery. I always wondered how they got such smooth results in professional games.
Learned English and bought a BBC Model B almost 40 years ago. As a non academic and my late father had a strong opinion of studying, was wastage of time it was a huge step. Learned BBC Basic and typed a lot of code from magazines. I tried to learn assembler and it was a steep learning curve. After realizing that assembler is another way of making branches, loop e.g. it helped a lot. Then when writing a disassembler I also realized that it's all about numbers and how they give meaning. I had almost a Caste Quest up and and running. I had similar issues trying to make graphics. I had made the figure from Castle Quest so it would move down on the screen, when the pixels were black, so sometimes the figure took a trip through the memory and make the relay to cassette recorder rattle. :o) I have worked in the IT-world since. Because I'm now learning the C language and therefore are curios about C, was one of the many programming languages for the BBC Micro?
You can see the clock speed on the zalaga game the way the sprites move a few pixels at a time in a sequence you can see the floating point you can see how hard it was to build 3d polygons and scroll multiple 3d structures really needed a faster cpu
I saw my name in your video at the start, LOL and I know your pain. It's a shame you couldn't get Swift to work. The last time I used that was 2008. I give myself the same challenge and wrote a space invaders clone on the BBC B - it's called Sparse Invaders and you can get the ssd and all the source code at that site you were on - RetroSoftware. I also put a base shell source project that give you the functionality you needed to develop a game. Anyway, your doing it the hard way paid off, so you understand the way of the machine, and it's a great feeling to get IT working! Great video.
The interrupt based sprite routine in that book is very good. I've used it and expanded on it for single pixel movement in mode 2. It sets up an interrupt triggered by the frame interrupt and draws the sprites when that goes off. You set the timer to give you enough time to draw your sprites. You can give yourself more time by prioritising your sprites based on vertical position. The screen layout of the bbc isn't straightforward. It's more straightforward than the spectrum screen though.
I almost made a robotic arm but my life changed direction and that idea is now just a memory. I did build some disco lights as programming them was easy. Buy some small LEDs to start with and write a program to light them up in the patterns you require. That is a good project for staters and it will allow you to see the effected of switching each port on on off. I also build an analogue joystick, so some potentiometers are a good purchase to show how the BBC can handle variable input signals. Oops this is three years old. lol
Interesting stuff. The interrupts and raster issues are pretty much the same for most 8 bit computers. You have hardware sprites on the C64, but then have to chase the raster to display more of them on the screen. The whole concept of having to code sprites at the lowest level would be of interest to speccy, Plus/4 developers, etc who have to do the same. A link to the code would have been nice, though I expect there's quite a bit available if you look.
After delving so deep into a special topic, my regulary problem is, that I have forgotten most of it when trying to pick up the thread again some weaks later... 😅
I wrote a bunch of games using Simonsoft's sprites and sold them to Micronet800 for pocket money. Sorted me a career in software engineering! Could never understand assembly, though. How shifting bits through registers and stacks results in space invaders bamboozles me.
Can you provide a link to the Flow Chart you created please? I'm interested in potentially using the SpritePlotter module and this would help me understand it.
Great video, bbc micro was my first computer. I made the robot based on the book you mentioned at the end of your vid. I did this for part of my gcse design and tech...if you build the circuit design in the book pleeese test your relays before connecting to the user port. watch out, you will fry the main board!! Learned from experience... Keep going!!!
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.
We got a model b as our families computer when I was, er, 3 I think. After learning how to load games I started picking through the spacing guide and writing my own software I got the assembly book out of the library and tried learning 6502 ASM Sadly it just didn't click, I couldn't grasp it beyond peek, poke, ldr and add or shift. So I stuck to basic. It's only now that I realise what was on screen was mapped to ram. I've still got it and my a3000. When we move to a house I get to have a workshop, can't wait to service it and write some games.
As a kid I just didn't understand what the machine was doing, there wasn't any easy obtainable documentation. Or actually there wasn't anything telling me that I could do more than load things off tape, or type in basic listings. My local library was a bit rubbish, and it's not easy learning something you don't know exists.
@@ncot_tech Tell me about it We had the documentation, obviously because they were new and pervasive All the way through school, they did everything, CNC lathes, Domesday, I remember one controlling a telescope at the observatory. What frustrated me, was the total lack of documentation for my A3000. That machine was, and still is until I learn it, a total mystery. I had some WIMP apps written in basic and I wrote physics sims on it too. Learning FPGA and SDR for giggles at the moment. I have half a mind to design my own computer on an FPGA. Have you played with the bbcmicrobot on Twitter yet?
Really interesting, is there a way to adjust the timer to trigger in a more independent way that relies less (or not at all) on the amount of code or speed of the code? Like setting it to fire every nth of a second?
That's a situation where it's probably quicker to figure it out yourself, than get the old code running. So. it's like life ! No one knows what is going on !
Actually, I find those frustrating moments the best part of programming. The parts were one is just typing generic design patterns are (to me) only one step above typing BASIC code in from a magazine (where did they all go?). I suspect the most creative programming is done far away from the keyboard. I can remember one bug: I had typed [ if(x = date){ ] but a rather large function was screwing up, reading and reading the code did not reveal the error. The solution popped into my brain on a station platform many miles from the keyboard or a printout, I should have written [ if(x == date){ ]. It is a newbie mistake but it is a demonstration of how deeply a programmer can get into his code. The Beeb was a very interesting computer, back in the early 80s, the only documentation was the manual one got with the machine. Now, this was an excellent manual. It helped the beginner through BBC Basic, Each and every operating system call and even 6502 assembly language ( this could be embedded into a basic program). Nevertheless, this was only scratching the surface. To give an example of what could be done: the space shoot 'em up game, Elite (the only game I ever got addicted to) had to change the graphics mode of the screen display 4 times EVERY FRAME to produce a display with the highest resolution view of the space (monochrome) and a four colour representation of the control instrumentation. I never find out how it was done; I didn't really want to look behind the curtain.
Been a developer as a job for over 30 years now. Got my Beeb in 83 after replacing a Spectrum for it. To this day I reckon the cassette version of Elite on the Beeb is the best bit of games programming I've seen.
You need to make a language that you can the create a compiler in bbc asm that compiles the language in to bbc asm 😜 the rewrite the compiler in your new language and iterate until you’ve re invented the wheel, tyre, air, physics.
I have two sons and I know for a fact that knowing programming would help them in the real life (teaches very specific problem solving skills which translate to real life quite easily), and I know how hard it is both "dumb down" the ideas, as well as "not actually dumbing them down and not patronising" when all the time you are trying see that spark in there - I've managed to teach programming to a few friends in my life, and the average has been about 8 weeks to see the spark. And I know that you understand what I mean by the "spark".
I get the impression that people are kinda cagey about their discoveries as to the undocumented aspects of this machine. Lots of games and not much account of the processes involved in their creation. There's something distinctly twatish about that.
Nope, we had to read books and do everything the hard way. The best we had was some maths teacher who'd "been on a course" and borrowed the school Beeb over summer.
Well done! Assembly programming is one of the most rewarding. (I'm "normally" a c/c++ developer Monday to Friday)
Subscribed! Brings back memories of writing assembler for the first time when I was about 10. I was 7 when I had my first computer, the BBC B in early 1982. It started a fascination and deep love of electronics and computing that continues today.
Very nice story that bring back a lot of memories :o)
A trick I'm using when I need to time vertical blanking interrupt code is to change the border or background color at the beginning and end of my routine. That allows to visually see where the beam is during execution (ideally it starts just under the display area in the bottom and finish just before the top of the same display area).
One of the most ground breaking games ever was first released on the BBC Micro........Elite!
Super interesting, would be great to see a video explaining some of the software you were using on the pc, and the general process, the bbc is an amazing piece of tech. Looking forward to your game release lol
Excellent as always. Some really useful book recommendations, too.
Had a lot of fun trying to write sprite routines and multiplication routines for matrices back in the day
I learnt all my BBC hardware knowledge from the Advanced User Guide.
The vsync starts the vertical retrace, which is where the raster beam goes back to the top and takes about 5 character rows (this is an educated guess).
By default, this is at the 34th character row when 32 rows are displayed and a frame is 39 long.
If you really want to see some chasing the beam on the BBC Micro, take a look at my Frogger game :)
ruclips.net/video/ekcbTWSFbWg/видео.html
Amazing! I spent my childhood trying (and failing) to write games for the BBC but the sprites were always slow and flickery. I always wondered how they got such smooth results in professional games.
Learned English and bought a BBC Model B almost 40 years ago. As a non academic and my late father had a strong opinion of studying, was wastage of time it was a huge step. Learned BBC Basic and typed a lot of code from magazines. I tried to learn assembler and it was a steep learning curve. After realizing that assembler is another way of making branches, loop e.g. it helped a lot. Then when writing a disassembler I also realized that it's all about numbers and how they give meaning. I had almost a Caste Quest up and and running.
I had similar issues trying to make graphics. I had made the figure from Castle Quest so it would move down on the screen, when the pixels were black, so sometimes the figure took a trip through the memory and make the relay to cassette recorder rattle. :o)
I have worked in the IT-world since.
Because I'm now learning the C language and therefore are curios about C, was one of the many programming languages for the BBC Micro?
You can see the clock speed on the zalaga game the way the sprites move a few pixels at a time in a sequence you can see the floating point you can see how hard it was to build 3d polygons and scroll multiple 3d structures really needed a faster cpu
I saw my name in your video at the start, LOL and I know your pain. It's a shame you couldn't get Swift to work. The last time I used that was 2008. I give myself the same challenge and wrote a space invaders clone on the BBC B - it's called Sparse Invaders and you can get the ssd and all the source code at that site you were on - RetroSoftware. I also put a base shell source project that give you the functionality you needed to develop a game. Anyway, your doing it the hard way paid off, so you understand the way of the machine, and it's a great feeling to get IT working! Great video.
The interrupt based sprite routine in that book is very good. I've used it and expanded on it for single pixel movement in mode 2. It sets up an interrupt triggered by the frame interrupt and draws the sprites when that goes off. You set the timer to give you enough time to draw your sprites. You can give yourself more time by prioritising your sprites based on vertical position. The screen layout of the bbc isn't straightforward. It's more straightforward than the spectrum screen though.
Ahh, that is my sprite code. I wrote the Swift dev kit you were referencing. It does need updating to not use p65 etc.
I almost made a robotic arm but my life changed direction and that idea is now just a memory. I did build some disco lights as programming them was easy. Buy some small LEDs to start with and write a program to light them up in the patterns you require. That is a good project for staters and it will allow you to see the effected of switching each port on on off. I also build an analogue joystick, so some potentiometers are a good purchase to show how the BBC can handle variable input signals. Oops this is three years old. lol
Interesting stuff. The interrupts and raster issues are pretty much the same for most 8 bit computers. You have hardware sprites on the C64, but then have to chase the raster to display more of them on the screen. The whole concept of having to code sprites at the lowest level would be of interest to speccy, Plus/4 developers, etc who have to do the same. A link to the code would have been nice, though I expect there's quite a bit available if you look.
brilliant stuff! I'm looking forward to seeing more about your game! 👍
After delving so deep into a special topic, my regulary problem is, that I have forgotten most of it when trying to pick up the thread again some weaks later... 😅
Fascinating. Thank you for uploading
I wrote a bunch of games using Simonsoft's sprites and sold them to Micronet800 for pocket money. Sorted me a career in software engineering! Could never understand assembly, though. How shifting bits through registers and stacks results in space invaders bamboozles me.
Can you provide a link to the Flow Chart you created please? I'm interested in potentially using the SpritePlotter module and this would help me understand it.
Great video, bbc micro was my first computer. I made the robot based on the book you mentioned at the end of your vid. I did this for part of my gcse design and tech...if you build the circuit design in the book pleeese test your relays before connecting to the user port. watch out, you will fry the main board!! Learned from experience... Keep going!!!
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.
We got a model b as our families computer when I was, er, 3 I think.
After learning how to load games I started picking through the spacing guide and writing my own software
I got the assembly book out of the library and tried learning 6502 ASM
Sadly it just didn't click, I couldn't grasp it beyond peek, poke, ldr and add or shift.
So I stuck to basic.
It's only now that I realise what was on screen was mapped to ram.
I've still got it and my a3000.
When we move to a house I get to have a workshop, can't wait to service it and write some games.
As a kid I just didn't understand what the machine was doing, there wasn't any easy obtainable documentation. Or actually there wasn't anything telling me that I could do more than load things off tape, or type in basic listings.
My local library was a bit rubbish, and it's not easy learning something you don't know exists.
@@ncot_tech
Tell me about it
We had the documentation, obviously because they were new and pervasive
All the way through school, they did everything, CNC lathes, Domesday, I remember one controlling a telescope at the observatory.
What frustrated me, was the total lack of documentation for my A3000.
That machine was, and still is until I learn it, a total mystery.
I had some WIMP apps written in basic and I wrote physics sims on it too.
Learning FPGA and SDR for giggles at the moment.
I have half a mind to design my own computer on an FPGA.
Have you played with the bbcmicrobot on Twitter yet?
Really interesting, is there a way to adjust the timer to trigger in a more independent way that relies less (or not at all) on the amount of code or speed of the code? Like setting it to fire every nth of a second?
The beeb has several very flexible hardware timers
When this is mastered the next challenge is the Atari 2600. The programmers in 1977 were gods.
Been down this rabbit hole donkey's years ago.
Good work 👍
Love it!
That's a situation where it's probably quicker to figure it out yourself, than get the old code running. So. it's like life ! No one knows what is going on !
I learned to code in Dixons and WH Smiths
Once beam calibrated does it look right on the real hardware?
Actually, I find those frustrating moments the best part of programming. The parts were one is just typing generic design patterns are (to me) only one step above typing BASIC code in from a magazine (where did they all go?). I suspect the most creative programming is done far away from the keyboard. I can remember one bug: I had typed [ if(x = date){ ] but a rather large function was screwing up, reading and reading the code did not reveal the error. The solution popped into my brain on a station platform many miles from the keyboard or a printout, I should have written [ if(x == date){ ]. It is a newbie mistake but it is a demonstration of how deeply a programmer can get into his code.
The Beeb was a very interesting computer, back in the early 80s, the only documentation was the manual one got with the machine. Now, this was an excellent manual. It helped the beginner through BBC Basic, Each and every operating system call and even 6502 assembly language ( this could be embedded into a basic program). Nevertheless, this was only scratching the surface. To give an example of what could be done: the space shoot 'em up game, Elite (the only game I ever got addicted to) had to change the graphics mode of the screen display 4 times EVERY FRAME to produce a display with the highest resolution view of the space (monochrome) and a four colour representation of the control instrumentation. I never find out how it was done; I didn't really want to look behind the curtain.
Been a developer as a job for over 30 years now. Got my Beeb in 83 after replacing a Spectrum for it. To this day I reckon the cassette version of Elite on the Beeb is the best bit of games programming I've seen.
With a 2MHz 6502 the BBC has got to be good for 3d games like Elite, Mercenary, etc. The C64 would have struggled to keep up.
That ground-breaking game, Elite, was indeed first released on the BBC Micro, and yes, it did play faster than the competing C64.
You need to make a language that you can the create a compiler in bbc asm that compiles the language in to bbc asm 😜 the rewrite the compiler in your new language and iterate until you’ve re invented the wheel, tyre, air, physics.
I have two sons and I know for a fact that knowing programming would help them in the real life (teaches very specific problem solving skills which translate to real life quite easily), and I know how hard it is both "dumb down" the ideas, as well as "not actually dumbing them down and not patronising" when all the time you are trying see that spark in there - I've managed to teach programming to a few friends in my life, and the average has been about 8 weeks to see the spark. And I know that you understand what I mean by the "spark".
I get the impression that people are kinda cagey about their discoveries as to the undocumented aspects of this machine. Lots of games and not much account of the processes involved in their creation. There's something distinctly twatish about that.
No such thing as computer science teachers then
Nope, we had to read books and do everything the hard way. The best we had was some maths teacher who'd "been on a course" and borrowed the school Beeb over summer.
Next time, try to speak out words more clearly. Thanks.
Nothing wrong with his elocution, it's fine. The problem is between your ears.
@@PJBonoVox You're wrong. There is. But yeah, the problem is IN your ears.
Try writing a game on a microcontroller board that doesn't even have a video chip or circuit (until you've made one yourself that is) 🫣