My proudest magazine moment was when after my (atari ST) game was published on the ST Format cover disk and I got my 50 quid, I got a random floppy disk in the post from some cracking group who'd taken the time to make a cracked and trained version of my game, that was used as a filler with a cracked commercial game. For some reason I found that way cooler :-) This visual-6502 stuff is bonkers. Very cool.
4 роки тому
That feeling when you got your work published...fantastic. I had a platform game designer utility for the CBM64 published in Commodore Disk User waay back in day. I thought I lost my original mag + disk for good till I found out about things like the Internet Archive...that was a huge pick-me-up. I could read the mag again and run the programs and play demo game (and even improve the game via modern tools like CBM Prg Studio). I've stored that original image in a bunch of places lol. Different times indeed - I fail often in trying to get across to young programmers just what living without the internet meant for programming. In those days the only way you continued and developed to an expert level with so many obstacles (lack of docs, examples, etc etc) was via a true 'love of the art'. Thinking outside the box was #1 requirement...in fact there was no pre-defined box lol. You also HAD to answer your own questions AND innovate. Traits very sadly lacking in today's high level, scripting world.
The thing he said about varying the volume register to play digitized sounds. On the C64 at least, the original SID chip had a leaky op-amp at the output pin (the designer, Yannes, knew this but didn't have the time to fix it properly) which output a DC level proportional to the master volume. What this meant was you could play 4-bit digis by piping them directly to the volume register. I love this kind of stuff!
This video brought back some good memories from the many hours I spent hacking games on the BBC micro, stepping through code with Exmon II looking for infinite lives pokes and other cheats. I too tried to write an emulator to crack one of my games that used hardware timers s in it's copy protection, but I had to admit defeat; it was a great challenge though.
One error in the talk: You certainly can compare with both X and Y index registers on the 6502.
4 роки тому
CPX #$40 BEQ ... ... CPY #$14 BNE ... etc etc I loved those days back in the 80's. Today, the internet, while having it's pluses, has it's negatives too - other people do the problem solving for you. Also, Game engines and scripting languages - a necessity but takes away from what real programming is all about. Unity anyone?
@ Ironically I made my own Chip-8 Emulator in MonoGame a few days ago. Now I'm completely hooked on learning the fundamentals of a CPU. I thought I new something, but I really hardly new anything other than how to shove it in a motherboard lmao
Fascinating how you count cycles to change graphics modes in the middle of generating the display. This clever hack essentially implements what the Atari 800's graphics system did with a display list. Essentially it was a program for the graphics chip that said what mode to use for each line (with the option for an interrupt at the end of any given line). But Atari set it's processor speed to match the speed of the CRT scan to allow the exact same tricks you described. There are games where they used cycle counting to know how far over in each line the drawing was so that they could change the color registers for a section of the screen. (On the Atari, you had one-byte color registers, but depending on the graphics mode, usually had only four available (two bits per pixel identifying the color register to use.) I suspect the Atari 2600 pioneered such techniques, so system designers after that made sure the timings would work correctly. Interestingly, this means the PAL Ataris ran at a slightly different speed from the NTSC Ataris, and not all games took this into account. All that means that many arcade-style games did all the logic during the vertical blank period where the electron beam was turned off to reset from the bottom right to the top left for the next frame. The vast majority of the CPU power was used to manage the graphics, even with Atari's advanced (for the day) graphics chips.
Pretty much everyone, who's anyone in computing today, learned computing using BASIC and assembler, but we're still trying to push Python and Javascript on 9 year olds. We need to go back to simple machines, simple computing environments to make kids learn about computing. we're teaching them gigantic obj-oriented frameworks and it's really not fair to kids.
Gosh, it seems so ironic that In Britain, a television studio would foster educational programs in such a profound way; whereas in the States, television has been deliberately dumbing us down...
The BBC had a mission statement to inform, educate and entertain. Now they have watered down the education, and added discriminate. So they are now very much now a social Marxist organisation.
The BBC indoctrinated our nation. Now with the internet people have woken up to the fact and broken away from that indoctrination, which makes the Saudi Royalty very sad.
+Nick Hill, your profile pic automatically makes me disregard your comment. Also, "social marxism" lol That stupid term is still being employed as if it meant something, I see
I'd like to know what the actual speed of the emulation is. Since you mentioned things that needed special optimization, I gather that the detailed timing-step emulation has trouble keeping up with real-time?
It's a bit tricky, but there are some hacks that can be done in software to achieve it. You don't necessarily want to try to emulate the exact MHz through your main loop directly. You need to know the cycle count of each instruction, is it a 3 cycle, 4, 5, etc... then you also need to know what type of instruction, addressing mode, etc. it is in order to know which physical device it is going to talk or interact with next. This is important because in some systems such as the NES there is more than 1 bus! The multiple buses may not operate at the same exact frequency, but what is normally constant is the rate at which the device operates depending on the type of instruction. A register read will in many cases be shorter than a register write. This is typical but it also depends on the hardware design such as write protection, caching techniques, pipeline, pipelining, etc... So you have to pretty much understand the entire ISA, the internal components of the hardware, how they are connected, how they operate, and how they interact with other devices in specific contexts... Yes, this is a mouth full and isn't a straight-up answer but this is the kind of upfront knowledge, research, and thinking that goes into hardware emulation. It's not easy! So in a sense, if you know the ratios of the general time taken for a specific device to do its, job and report or talk to the bus and you know which bus it is talking across and where it is going, then you can generalize this... // arbitrary pseudo code // CPU cycles depend on the instruction type // We will assume that all instructions take at least 3 cycles, fetch, decode and execute where others may take 4 or 5... // InsA = 3 cycles, InsB = 4 cycles, InsC = 5 cycles.... // This could be the fetch cycle. The main bus is calling its readCPU function to get the information from the CPU's fetch cycle, // the cpu is reading data from memory where &data is the pointer in memory... We don't know what the instruction is just yet... mainBus.readCpu( cpu.read(&data) ); // Now this data that is passed to the CPU is now stored into the CPU's cache bank or internal register that is for decoding instructions. // the CPU will internally decode this and output the appropriate value from its internal decoder that is going to be sent out to the bus to be executed. // cpu.decode(&data) could be called within the read function of the CPU class. The value may or may not need to be saved to the cpu's internal buffer so we should cache it in a local temporary before decoding it. It depends on the type of instruction and or data it will need to be saved before processing and modifying it. If it's a jump, return from a subroutine, etc. it'll need to know the current "stack pointer's value, as well as the current instruction memory address... etc. If it's just a simple LDA immediate instruction, then it wouldn't need to save it. Before the decoding takes place the original (data) value should be cached into a local temp in case it needs to be saved for later. If it does then the original value isn't lost so that the passed by reference can be modified by the decoder and can be updated accordingly. Otherwise, the cached value can be ignored and will be discarded afterward... // Let's say &data had InsA that is 3 cycles such as LDA #$20. The data value would contain something like 0xA920 which would be a 16bit value. Even though it is an 8-bit system. It would parse this and now the CPU knows to load the value 0x20 or 32 in decimal into register A. It doesn't need to save the original (data) so the cpu's member variable will not be overwritten. Now the CPU has to put this value of 0x20 onto the bus along with the control lines or signal to enable write to register A. So this may now look something like 0x0120 where the 01 would be to trigger the write for the A register and the 20 would be the hex value to store. Data is now updated and that is passed into the bus by reference and the readCPU function would return a value of 3 to the bus for the cycle count. Something of this context could be used. There are other ways to design this in software. Hashmaps can work, lambda function calls can work, function pointers can work, meta templating, even bit twiddling, etc. There are many ways to design this in software. And these function calls would consist of the first 2 microinstructions that are typically common with all instructions (fetch and decode). Now all that is left is to use the value that is passed to the bus to determine the ratio of the (CPU execute), or other connected hardware such as PPU or APU, etc, ROM read, etc. If the instruction took 5 CPUs, instead of 1 cycle left, there would be 2 extra cycles. These values can determine the ratio of device calls within the loop. Now, there are possibly some (exceptions) as well as (interrupts) that have to be dealt with as well and in uncommon cases, either a 1 cycle no-op or a 2-cycle unconditional jump that needs to be dealt with. Now the main loop itself wouldn't be stimulated to run at (2.4 MHz) directly. What would be done, would be to set the loop to run in a frame buffer with a target frame rate of say 30 or 60 fps... and depending on the ROM and how it behaves, this target FPS might have to be adjusted which could be done either dynamically by the program(emulator, engine) itself or through user application input control that would save to a configuration file or settings file as they could adjust it at runtime, or both... So, in the end, you can "generalize" the hardware itself in software, but when it comes to the many "roms" out there that would be emulated on it, you might have to debug and tweak each and every room, find out what does and doesn't work and how to fix them or "hack" them to work. Then, write them to an initialization file that would be a part of the emulators supported ROM list... so if someone has that ROM, that "ini" file would be loaded in. However, for something like this to work, the user would have to follow a specific naming convention of the "ROM" files for it to work or load both files in order to retrieve the appropriate "INI" for that "ROM"! Yes, I know that this was quite a bit to take in and quite wordy, but this is only the tip of the iceberg when writing emulators. Take for example the NES. To get the CPU and Bus components working with all of the known and unknown instructions isn't too bad. Now include the PPU, and the APU, and the other busses, now include the ROM Cartridge link or reader... Some Cartridges have small internal RAM... which has to be taken into consideration. Then it's a matter of linking and synchronizing them to work together in an integrated fashion. After that, know you have to handle the sprites, as well as all of the supported mappers. Then you would have to figure out what kind of hidden techniques different developers used to layout their information, index specific addresses, using interrupts at specific times, etc... so there is a lot that goes into emulation! For, a software program to be called an emulator it should be able to perform all possible operations as the hardware it is emulating including the internal hardware bugs if known!
I have only just discovered this BBC emulator. I actually programme educational physics simulations using Javascript. My first computer after graduating (in engineering) was a BBC Model B Microcomputer and yes I bought a lot of the games that are now playable in your browser using this amazing emulator. Starship Command, Elite, Acorn Arcade Action, Frak! etc Unfortunately I sold my BBC computer for about £300 with all the software and a floppy drive. I remember the floppy drive cost as much as the computer. It was replaced with an Amiga 500, which I still have. I remember before I bought the BBC computer I went to a computer exhibition in London and Acorn/BBC had a stall, no computer to see, just a colour brochure. I decided then and there to buy one even though Acorn had no hardware, other work colleagues bought Spectrums... and then the witty banter started. The great British tribal battle between BBC and Spectrum owners/gamers. Elite almost killed my social life and my friends couldn't understand my obsession with the game.
Just thought... Just need someone now to take an ARM processor that is running Javascript, placed in/on a board with some additional logic that emulates the 6502 signals on the processor pins. The board would be the same size as the original 6502 and have the inline pins down each side of the package. So basically you would have a 6502 processor, but inside it there will be an ARM chip running Javascript on top of an OS etc. You could then take a real BBC computer, place the ARM/Javascript/6502 processor in the original 6502 processor slot on the BBCs PCB and run BBC software on it. Then in 50 years time someone will write an emulator that mimics the ARM/Javascript/6502 processor using a Quantum processor using QSscript, then someone will suggest making an ARM/Javascript/Quantum/QSscript/6502 processor. Then in 100 years...
This has been done (not in Javascript though): stardot.org.uk/forums/viewtopic.php?t=11325 Raspberry Pi runs a 6502 emulator, and then connects to the coprocessor interface on a Beeb using the GPIO.
ROFL - I got started on an Atari 400 and I also wrote a program for a national computer magazine (Softside). I only got $50 for it but I was very excited over it. I even sent a copy to my Mom. It was a game written in Atari Basic (a very SLOW basic) but it's string manipulation code was very fast so I fool basic into thinking my graphics area was a large string and was able to move 4 volleyball players and the ball very quickly.
Using a switch case statement for emulation is bad practise and leads to bad performance. You may want to use an array of functions with a function for every instruction. That way the opcode can be used as an index into that array instead of doing hundreds of compares per instruction.
I find this fascinating but I don't quite understand where to learn 6502 assembly efficiently on the web. I could get a book but I'm always afraid of trying to learn a programming language with books. I prefer to follow good video classes, and then complement it with all the documentation there is online.
That was frustrating. He spends almost all his time on a read-through of how the original 8bits worked and very little time on describing how the emulator works.
Calling the 1980's BBC The Computer Programme "Universally dreadful"?! How very dare you! Shame on you, they were fucking awesome. Respeck your elders, boy! Ian McNaught-Davis 'Mac' would be spinning in his grave hearing you slander his show like that. xP
Even for when this talk came out, that whole bit about the hardships of using emulator around 11 minutes is the dumbest thing I've heard in a while. Either that or he's on the level of elitism where "software doesn't count if you don't compile it yourself".
This might have been interesting if was on implementing using Rust - or Verilog for an FPGA implementation (e.g., MiSTer), but all these crap emulators written in JavaScript so they can run in a browser window are just the worst. Expectations have moved on. Software emulators of any stripe are no longer adequate. The only emulators that are satisfying now are the FPGA implementations. The MiSTer project has set a very high bar and everything else by comparison to it is just pathetic.
My proudest magazine moment was when after my (atari ST) game was published on the ST Format cover disk and I got my 50 quid, I got a random floppy disk in the post from some cracking group who'd taken the time to make a cracked and trained version of my game, that was used as a filler with a cracked commercial game. For some reason I found that way cooler :-) This visual-6502 stuff is bonkers. Very cool.
My proudest magazine moment was when after my (atari ST) game was published on the ST Format cover disk and I got my 50 quid, I got a random floppy disk in the post from some cracking group who'd taken the time to make a cracked and trained version of my game, that was used as a filler with a cracked commercial game. For some reason I found that way cooler :-)
This visual-6502 stuff is bonkers. Very cool.
That feeling when you got your work published...fantastic. I had a platform game designer utility for the CBM64 published in Commodore Disk User waay back in day. I thought I lost my original mag + disk for good till I found out about things like the Internet Archive...that was a huge pick-me-up. I could read the mag again and run the programs and play demo game (and even improve the game via modern tools like CBM Prg Studio). I've stored that original image in a bunch of places lol.
Different times indeed - I fail often in trying to get across to young programmers just what living without the internet meant for programming. In those days the only way you continued and developed to an expert level with so many obstacles (lack of docs, examples, etc etc) was via a true 'love of the art'. Thinking outside the box was #1 requirement...in fact there was no pre-defined box lol. You also HAD to answer your own questions AND innovate. Traits very sadly lacking in today's high level, scripting world.
Amazing video, brings me back to 13 years old trying to learn assembly on my Apple II+. This completely demystifies emulators for me. Thanks
What a 8 bit chip could do is impressive !
excellent talk! amazingly in-depth but very understandable. and didn't waste any of my time!
The thing he said about varying the volume register to play digitized sounds. On the C64 at least, the original SID chip had a leaky op-amp at the output pin (the designer, Yannes, knew this but didn't have the time to fix it properly) which output a DC level proportional to the master volume. What this meant was you could play 4-bit digis by piping them directly to the volume register. I love this kind of stuff!
This video brought back some good memories from the many hours I spent hacking games on the BBC micro, stepping through code with Exmon II looking for infinite lives pokes and other cheats. I too tried to write an emulator to crack one of my games that used hardware timers s in it's copy protection, but I had to admit defeat; it was a great challenge though.
One error in the talk: You certainly can compare with both X and Y index registers on the 6502.
CPX #$40
BEQ ...
...
CPY #$14
BNE ...
etc
etc
I loved those days back in the 80's. Today, the internet, while having it's pluses, has it's negatives too - other people do the problem solving for you. Also, Game engines and scripting languages - a necessity but takes away from what real programming is all about. Unity anyone?
@ Ironically I made my own Chip-8 Emulator in MonoGame a few days ago. Now I'm completely hooked on learning the fundamentals of a CPU. I thought I new something, but I really hardly new anything other than how to shove it in a motherboard lmao
Fascinating how you count cycles to change graphics modes in the middle of generating the display. This clever hack essentially implements what the Atari 800's graphics system did with a display list. Essentially it was a program for the graphics chip that said what mode to use for each line (with the option for an interrupt at the end of any given line). But Atari set it's processor speed to match the speed of the CRT scan to allow the exact same tricks you described. There are games where they used cycle counting to know how far over in each line the drawing was so that they could change the color registers for a section of the screen. (On the Atari, you had one-byte color registers, but depending on the graphics mode, usually had only four available (two bits per pixel identifying the color register to use.) I suspect the Atari 2600 pioneered such techniques, so system designers after that made sure the timings would work correctly. Interestingly, this means the PAL Ataris ran at a slightly different speed from the NTSC Ataris, and not all games took this into account.
All that means that many arcade-style games did all the logic during the vertical blank period where the electron beam was turned off to reset from the bottom right to the top left for the next frame. The vast majority of the CPU power was used to manage the graphics, even with Atari's advanced (for the day) graphics chips.
Wow. Just 3510 transistors. And look at what it could do! The latest AMD K10 has 758 MILLION transistors. Crazy.
Pretty much everyone, who's anyone in computing today, learned computing using BASIC and assembler, but we're still trying to push Python and Javascript on 9 year olds. We need to go back to simple machines, simple computing environments to make kids learn about computing. we're teaching them gigantic obj-oriented frameworks and it's really not fair to kids.
I liked the JIT English->American translations that were going on ;-)
Zeee 80
Gosh, it seems so ironic that In Britain, a television studio would foster educational programs in such a profound way; whereas in the States, television has been deliberately dumbing us down...
The BBC had a mission statement to inform, educate and entertain. Now they have watered down the education, and added discriminate. So they are now very much now a social Marxist organisation.
The BBC indoctrinated our nation. Now with the internet people have woken up to the fact and broken away from that indoctrination, which makes the Saudi Royalty very sad.
+Nick Hill, your profile pic automatically makes me disregard your comment. Also, "social marxism" lol That stupid term is still being employed as if it meant something, I see
Russian Bot What does my haircut have to do with my supposed political spectrum and ideology? Nice try, tho
@@nickhill9445 There are probably as many people who believe it to be a right wing mouth piece, but each to their own.
For the deferred sound, he said come talk to him afterward. I can think of ways to do it but it would be nice to know how it was done.
Great talk! More....More....:)
I'd like to know what the actual speed of the emulation is. Since you mentioned things that needed special optimization, I gather that the detailed timing-step emulation has trouble keeping up with real-time?
It's a bit tricky, but there are some hacks that can be done in software to achieve it. You don't necessarily want to try to emulate the exact MHz through your main loop directly. You need to know the cycle count of each instruction, is it a 3 cycle, 4, 5, etc... then you also need to know what type of instruction, addressing mode, etc. it is in order to know which physical device it is going to talk or interact with next. This is important because in some systems such as the NES there is more than 1 bus! The multiple buses may not operate at the same exact frequency, but what is normally constant is the rate at which the device operates depending on the type of instruction. A register read will in many cases be shorter than a register write. This is typical but it also depends on the hardware design such as write protection, caching techniques, pipeline, pipelining, etc... So you have to pretty much understand the entire ISA, the internal components of the hardware, how they are connected, how they operate, and how they interact with other devices in specific contexts... Yes, this is a mouth full and isn't a straight-up answer but this is the kind of upfront knowledge, research, and thinking that goes into hardware emulation. It's not easy! So in a sense, if you know the ratios of the general time taken for a specific device to do its, job and report or talk to the bus and you know which bus it is talking across and where it is going, then you can generalize this...
// arbitrary pseudo code
// CPU cycles depend on the instruction type
// We will assume that all instructions take at least 3 cycles, fetch, decode and execute where others may take 4 or 5...
// InsA = 3 cycles, InsB = 4 cycles, InsC = 5 cycles....
// This could be the fetch cycle. The main bus is calling its readCPU function to get the information from the CPU's fetch cycle,
// the cpu is reading data from memory where &data is the pointer in memory... We don't know what the instruction is just yet...
mainBus.readCpu( cpu.read(&data) );
// Now this data that is passed to the CPU is now stored into the CPU's cache bank or internal register that is for decoding instructions.
// the CPU will internally decode this and output the appropriate value from its internal decoder that is going to be sent out to the bus to be executed.
// cpu.decode(&data) could be called within the read function of the CPU class.
The value may or may not need to be saved to the cpu's internal buffer so we should cache it in a local temporary before decoding it. It depends on the type of instruction and or data it will need to be saved before processing and modifying it. If it's a jump, return from a subroutine, etc. it'll need to know the current "stack pointer's value, as well as the current instruction memory address... etc. If it's just a simple LDA immediate instruction, then it wouldn't need to save it. Before the decoding takes place the original (data) value should be cached into a local temp in case it needs to be saved for later. If it does then the original value isn't lost so that the passed by reference can be modified by the decoder and can be updated accordingly. Otherwise, the cached value can be ignored and will be discarded afterward...
// Let's say &data had InsA that is 3 cycles such as LDA #$20. The data value would contain something like 0xA920 which would be a 16bit value. Even though it is an 8-bit system. It would parse this and now the CPU knows to load the value 0x20 or 32 in decimal into register A. It doesn't need to save the original (data) so the cpu's member variable will not be overwritten. Now the CPU has to put this value of 0x20 onto the bus along with the control lines or signal to enable write to register A. So this may now look something like 0x0120 where the 01 would be to trigger the write for the A register and the 20 would be the hex value to store. Data is now updated and that is passed into the bus by reference and the readCPU function would return a value of 3 to the bus for the cycle count. Something of this context could be used. There are other ways to design this in software. Hashmaps can work, lambda function calls can work, function pointers can work, meta templating, even bit twiddling, etc. There are many ways to design this in software. And these function calls would consist of the first 2 microinstructions that are typically common with all instructions (fetch and decode).
Now all that is left is to use the value that is passed to the bus to determine the ratio of the (CPU execute), or other connected hardware such as PPU or APU, etc, ROM read, etc. If the instruction took 5 CPUs, instead of 1 cycle left, there would be 2 extra cycles. These values can determine the ratio of device calls within the loop. Now, there are possibly some (exceptions) as well as (interrupts) that have to be dealt with as well and in uncommon cases, either a 1 cycle no-op or a 2-cycle unconditional jump that needs to be dealt with. Now the main loop itself wouldn't be stimulated to run at (2.4 MHz) directly. What would be done, would be to set the loop to run in a frame buffer with a target frame rate of say 30 or 60 fps... and depending on the ROM and how it behaves, this target FPS might have to be adjusted which could be done either dynamically by the program(emulator, engine) itself or through user application input control that would save to a configuration file or settings file as they could adjust it at runtime, or both...
So, in the end, you can "generalize" the hardware itself in software, but when it comes to the many "roms" out there that would be emulated on it, you might have to debug and tweak each and every room, find out what does and doesn't work and how to fix them or "hack" them to work. Then, write them to an initialization file that would be a part of the emulators supported ROM list... so if someone has that ROM, that "ini" file would be loaded in. However, for something like this to work, the user would have to follow a specific naming convention of the "ROM" files for it to work or load both files in order to retrieve the appropriate "INI" for that "ROM"!
Yes, I know that this was quite a bit to take in and quite wordy, but this is only the tip of the iceberg when writing emulators. Take for example the NES. To get the CPU and Bus components working with all of the known and unknown instructions isn't too bad. Now include the PPU, and the APU, and the other busses, now include the ROM Cartridge link or reader... Some Cartridges have small internal RAM... which has to be taken into consideration. Then it's a matter of linking and synchronizing them to work together in an integrated fashion. After that, know you have to handle the sprites, as well as all of the supported mappers. Then you would have to figure out what kind of hidden techniques different developers used to layout their information, index specific addresses, using interrupts at specific times, etc... so there is a lot that goes into emulation! For, a software program to be called an emulator it should be able to perform all possible operations as the hardware it is emulating including the internal hardware bugs if known!
is there a reason the var pc started out at the address 0xfffe? Something special about RAM that I'm missing?
Mr. Houghton that's what the PC is actually initialized to per the documentation.
@@jjgamepro16 Hm I think poweron reset address is actually at 0xfffc? 0xfffe is supposed to be BRK and IRQ address.
Amazing!
I have only just discovered this BBC emulator. I actually programme educational physics simulations using Javascript.
My first computer after graduating (in engineering) was a BBC Model B Microcomputer and yes I bought a lot of the games that are now playable in your browser using this amazing emulator. Starship Command, Elite, Acorn Arcade Action, Frak! etc
Unfortunately I sold my BBC computer for about £300 with all the software and a floppy drive. I remember the floppy drive cost as much as the computer. It was replaced with an Amiga 500, which I still have.
I remember before I bought the BBC computer I went to a computer exhibition in London and Acorn/BBC had a stall, no computer to see, just a colour brochure. I decided then and there to buy one even though Acorn had no hardware, other work colleagues bought Spectrums... and then the witty banter started. The great British tribal battle between BBC and Spectrum owners/gamers.
Elite almost killed my social life and my friends couldn't understand my obsession with the game.
Fantastic presentation. I would have liked to have heard much more.
Hi, this is really cool and amazing. is the emulator available online yer ?
all you have to do is google "acorn computer emulator". There seems to be a couple of them out there.
bbc.godbolt.org/
Good stuff! Would love to know how you deal with loading data like roms etc
All the data is loaded from public internet archives like the "Stairway to Hell"
Hey is that a noopcat in the front row? :)
I believe so :)
Just thought...
Just need someone now to take an ARM processor that is running Javascript, placed in/on a board with some additional logic that emulates the 6502 signals on the processor pins. The board would be the same size as the original 6502 and have the inline pins down each side of the package. So basically you would have a 6502 processor, but inside it there will be an ARM chip running Javascript on top of an OS etc. You could then take a real BBC computer, place the ARM/Javascript/6502 processor in the original 6502 processor slot on the BBCs PCB and run BBC software on it. Then in 50 years time someone will write an emulator that mimics the ARM/Javascript/6502 processor using a Quantum processor using QSscript, then someone will suggest making an ARM/Javascript/Quantum/QSscript/6502 processor. Then in 100 years...
This has been done (not in Javascript though): stardot.org.uk/forums/viewtopic.php?t=11325
Raspberry Pi runs a 6502 emulator, and then connects to the coprocessor interface on a Beeb using the GPIO.
ROFL - I got started on an Atari 400 and I also wrote a program for a national computer magazine (Softside). I only got $50 for it but I was very excited over it. I even sent a copy to my Mom. It was a game written in Atari Basic (a very SLOW basic) but it's string manipulation code was very fast so I fool basic into thinking my graphics area was a large string and was able to move 4 volleyball players and the ball very quickly.
Using a switch case statement for emulation is bad practise and leads to bad performance. You may want to use an array of functions with a function for every instruction. That way the opcode can be used as an index into that array instead of doing hundreds of compares per instruction.
Paul Reichbert _Computed Goto_ in C/C++ FTW!
Idk about javascript but this is generally what a switch in C/C++ gets turned into anyways.
Nerds Rock! \m/
Emulating a 6502 in GWBASIC
I find this fascinating but I don't quite understand where to learn 6502 assembly efficiently on the web. I could get a book but I'm always afraid of trying to learn a programming language with books. I prefer to follow good video classes, and then complement it with all the documentation there is online.
www.6502.org/source/
Yeah I was addicted to elite!
21:52 is beautiful.
he literally ripped off the intro about what the mos was in from the "Reverse engineering the 6502" from 2011
Cool stuff
That was frustrating. He spends almost all his time on a read-through of how the original 8bits worked and very little time on describing how the emulator works.
Cool
tough audience really
No1 puts an e on program anymore!
50 quid, er, 50 pounds 😊
Good, inspiring talk!
both 6502 and JS are abominations of the past... why, YT, why?!
My English too bad to look this video. T.T
Keep learning. It will be easy soon!
Try turning on English captions and/or slowing down the video?
Calling the 1980's BBC The Computer Programme "Universally dreadful"?! How very dare you! Shame on you, they were fucking awesome. Respeck your elders, boy! Ian McNaught-Davis 'Mac' would be spinning in his grave hearing you slander his show like that. xP
Even for when this talk came out, that whole bit about the hardships of using emulator around 11 minutes is the dumbest thing I've heard in a while. Either that or he's on the level of elitism where "software doesn't count if you don't compile it yourself".
The colorful steel neurochemically puncture because beaver laparoscopically harm plus a slow trapezoid. empty, salty canoe
It takes him almost 10 minutes to get to the point.
At least he's making something.
This might have been interesting if was on implementing using Rust - or Verilog for an FPGA implementation (e.g., MiSTer), but all these crap emulators written in JavaScript so they can run in a browser window are just the worst. Expectations have moved on. Software emulators of any stripe are no longer adequate. The only emulators that are satisfying now are the FPGA implementations. The MiSTer project has set a very high bar and everything else by comparison to it is just pathetic.
Could you sound any more pretentious? Go on, give it a go.
emulate a 6502... oooh cooool, ... do it in javascript... go home! using a bad ass scriptkidz language to emulate the really cool stuff ... no way.
My proudest magazine moment was when after my (atari ST) game was published on the ST Format cover disk and I got my 50 quid, I got a random floppy disk in the post from some cracking group who'd taken the time to make a cracked and trained version of my game, that was used as a filler with a cracked commercial game. For some reason I found that way cooler :-)
This visual-6502 stuff is bonkers. Very cool.