I modeled programs in BASIC, but used subroutines. Then I started to convert the subroutines to relocatable assembly routines. Over time, programs would become full assembly programs, and very fast. And since many of the routines were saved as pieces, I could graft together a new program from the saved routines, like a library, in a simple BASIC wrapper. What a time! Thanks for the awesome video!
My first paid programming job was 6502 on Apple //e. This was a fun trip down memory lane. While programming in assembler seems tedious, I found it actually kind of calming in a meditative way. When a complex routine finally worked, the rush was exhilarating. It felt like successfully building the Eiffel Tower out of LEGO.
Not as low level but similar in terms of being close to the hardware and your analogy of getting something complex to work... Try writing a 3D Graphics Application to produce 3D Procedural Terrain Generation using Vulkan writting in C/C++... now that's tough! OpenGL and DirectX is still a challenge but Vulkan has a much steeper learning curve! Next up is writing an NES 6502 Emulator along with the rest of the NES's hardware components in C++. After that finish with making an actual 8, 16 or 32 bit CPU from logic gates in Logisim, then translate that into HDL or VHDL... My next project when I can save a few extra bucks would be to buy some breadboard kits and follow along with Ben Eater on his 8 bit bread board CPU... I completely know what you mean by getting something complex to work and the success of doing it is like having the Hoover Damn built!
Though I'm Atari 800 fan, all the "weirdness" about Apple "hi res" graphics speaks about the brilliance and genius of Woz. He managed to take what is basically a monochrome signal and exploit the NTSC timing to get 6 colors out of it using a minimal number of chips. The dude is the level beyond next level.
Good Presentation! I produce games on the Apple ][. Apple ][ hires graphics have peculiarities for sure, but once you have routines that keep track of the memory lookup tables and bitmap shifts, you never have to think about them again. I wrote a whole arcade game engine last year for my first game Alien Downpour. Once the engine was done, the game came together quick. I wrote my current game OidZone using the game engine in about a month. I started programming using Merlin Pro 2.41 running in the applewin emulator. Last year I moved over to using the PC using a text editor with Merlin32 to assemble.
Wish i had learnt this back in the day. It seemed very mysterious to me at the time, seeing page after page of DATA 169,0,192,32...etc etc in computer magazine listings and having no clue what they did. Bought myself a commodore PET some years ago and taught myself ML, still learning of course but having fun. I get a great sense of satisfaction when a small program actually works! These days with the advent of the internet, online tools, windows based assembly programs, emulators and videos such as yours make it so much easier that I finally get to pull down the curtain on ML. Thanks!
Very interesting, thanks. I never owned an Apple II, but i have 'dabbled' with 6502 code, initially on a Commodore PET, and later on a BBC Micro. I did actually submit a MC program to one of the computer mags of that era. It was a program to convert any number from any base to any other base (e.g. binary to octal etc). I still own some BBC machines, but these days I just use them for games etc. I've tried some coding on the Apple II emulator (Virtual II) on my Mac, and it all works well. Thanks for the nostalgia trip.
It's actualy "technically" faster to use self-modifying code. The tightest loop is roughtly LDA #value LDX #0 ptr STA $0000,x INX BCC ptr INC ptr+2 BCC ptr now... you need to initialize ptr + 1 and ptr + 2 ... and you need to check finishing conditions ... but you can add those.
I often feel like it was a shame that I was too young to understand this stuff when it was relevant (cut my teeth in AppleSoft BASIC as a kid). Once I was old enough to grasp assembler, the Apple II was no longer relevant (and nostalgia hadn't yet kicked in like it is now). Of course back then you really had no way of actually learning this stuff unless you were lucky enough to stumble across the right book, and knew adults who could steer you towards them. Most adults I had access to at the time were really not on the level to do that.
I think when you were talking about LSB and MSB, you meant "byte" instead of "bit". I used to program in Z-80 and 8080 back in the 70s and 80s, on the TRS-80 model I computer. Great fun! You do a nice presentation. I learned a lot.
@Tea Leaves One question. In 9:05 or line number 14 to 16 you load with the LDA instruction 16 Bit values in a 8 bit accumulator register. Why does this work? All your 3 variables GRAPH, HIRES and PGONE you set up with the EQU instruction are 16 bit wide (4 Hex values), so why does your command "LDA GRAPH" etc. work? Did i miss something?
The addressing mode being used there is called “absolute”. The 16 bit value following the op code is used as the address to load ann eight bit value. So it’s not saying load the HIRES value into the accumulator, but rather load, the eight bit value at the memory location specified by HIRES.
Very cool to see this and bring back memories. When I was 16 I wrote a hybrid program, which was common of the day, that allowed me to edit the Bard’s Tale character disks. I released it as shareware at the time. I used basic for logic and user interface and ML routines for low level disks i/o. As an avid subscriber to Call A.P.P.L.E. And Nibble magazines I was always amazed at the versatility on the apple ][. I think the most impressive thing I had seen in during those years was the nibble article on creating a sound sampler using the audio port. It was pure magic on a machine just not made to be an audio/graphics killer app.
6:45 The exact reason is that store instructions on 6502 perform the store to the memory twice while the load instructions perform the load once. Go to visual6502 (www.visual6502.org/) to see this quirk in action. This means any device wired to trigger by stores would get triggered twice per write instruction. Therefore they decided to trigger the hardware by reads for precisely the same reason as why the hires screen is interlaced: to save chips.
Pardon the rookie question, since I'm fairly new to programming on the assembly level. And the vast majority of my experience with the 6502 is with the Commodore machines. But are soft switches like a really simple version of os calls or built-in macros? Because they kind of seem close to it, only turned on in a really weird way.
Not a rookie question at all, they're not intuitive. If you squint really hard you could view them that way, but they're even less sophisticated. A "soft switch" generally means "do anything to this location in memory and it does something." Notably, this means you can turn on graphics mode by writing a value to a memory location - but sometimes you can also do it just by READING that memory location. Sometimes reading vs writing a soft switch will do different things. The documentation always specifies whether you have to read, write, or if either works. I don't know where the term originated, but you can find Apple specific information in the Apple II Technical Reference Manual, which says: "The devices which decide between the various video modes, pages, and mixes are called 'soft switches'. They are switches because they have two positions (for example: on or off, text or graphics) and they are called 'soft' because they are controlled by the software of the computer." I don't know if the term "soft switches' was ever used outside of an Apple II context.
Since A already contained $00, you could have used TAY (transfer A to Y) on line 13, which would only have taken one byte and two cycles as opposed to two bytes and three cycles. Also, there was no need to increase LSB each time around the loop; you could have just increased Y with INY, which takes only 2 cycles as opposed to 5 .....
Thanks for the suggestions! One of the challenges of programming generally and assembly specifically is knowing when it's worth trading off readability for speed. I certainly wasn't trying for optimal efficiency here, but it would be interesting to know how much faster the changes you suggest would have made the program. Try it out and let us know!
@@peterb3398 In a project of mine, I've used a neat trick where I have to copy 4 bytes , and I also incidentally need a 4 at the end (it's part of a chain-plotting routine. 4 is the plot mode for move; and whenever we do a move, we want to save the co-ordinates so we can close the path later). So my code is like this: .copy_co-ords LDX #0 .copy_co1 LDA screenX, X STA lastmoveX, X INX CPX #4 BNE copy_co1 TXA \ here X=4 STA plotmode \ 4 is move JMP plot_point \ it will have its own RTS Now whenever one of the co-ordinates in the chain has a "move" instruction, we copy the co-ordinates. There are two bytes for the X co-ordinate and two bytes for the Y co-ordinate, units first; and when the copying is done, we have a handy four in our X register to set the plot mode! There are more cunning stunts later. If we have a close instruction immediately following a move instruction, we want to use that as shorthand to draw a rectangle: .close LDA plotmode CMP #4 BNE close1 INC plotmode \ 5 is draw line \ boring instructions to draw lines to 3 intermediate points missed out JMP plot_point .close1 JSR plot_point \ plotmode must already be draw LDX #0 .close2 LDA lastmoveX, X STA screenX, X INX CPX #4 BNE close2 JMP plot_point Plot mode 5 is "draw line". If the plot mode is 4, we know the last instruction must have been "move"; so we just use an INC instruction to change it to 5, draw round the intermediate points (using a modified version of the plot_point code that never gets called from anywhere else, so it's just inserted inline. It doesn't take up enough space to spoil any relative branches around it) and finally, copy back the last moved-to point before we return to the calling routine via plot_point. (A JSR instruction immediately followed by an RTS can be replaced with a JMP instruction, which is a "one-way" jump that does not save an address on the stack; so when we hit the final RTS of that subroutine, the address on top of the stack points to the instruction immediately after the JSR that called this subroutine.) This is all going to be Open Sourced eventually, so I am commenting my code for the benefit of future hackers :)
There is no need to LDA #PATT each time through the loop. Instead, you could INY and BNE LOOP. When this branch falls through, you could INC MSB, LDX MSB, CPX #$40, and BNE LOOP. This will run about 30% faster and take less progmem.
I'll try to be brief. I wrote the code in Applesoft Basic to play Qubic, or 3D Tic-tac-toe. It's played in a 4x4x4 format. There are 76 winning patterns of 4 in a row pieces. The player entered the level-row-column to make a move. E.G. square 111 was level 1, lower left space. My logic then would make a move (after seeing if the player had won). This reply could take as much as 45-60 seconds. I recoded the program logic in machine code, not assembly (technically the result would be similar). The new program would reply before the players finger left the enter key. I sold one copy to a fellow at Applefest in Boston around 1978?
I'd have written this a little differently, for faster speed. Starting after you switched to HiRes mode: LDX #$20 LDA #PATT LOOP: STA (LSB),Y INY BNE LOOP INC MSB DEX BNE LOOP BRK Your way is not bad, but it does waste a lot of optimization that hurts both speed and memory use. Good video, though.
Hi, Daniel! I actually walk through CALL -151, the monitor, and the mini-assembler in my previous video, ruclips.net/video/PNOj6GTzfGY/видео.html. So you're not alone!
@@TeaLeavesProgramming Great thanks. I've also come across Commander X16 (github.com/commanderx16/x16-emulator) Retro computer project- it's like a Modern Apple/C64. Nice.
And computers were so expensive in the early 80s. There was no way my parents would shell out . We did have a coleco vision. Which was amazing. But it didn’t have any development options. Like the Atari had apparently. Pretty sure that’s what mark zuck had as his first taste
It should be noted that 0x0000-0x00FF was RAM, but used for jump tables (I think), and 0x0100-0x01FF was the 6502 stack. Also, the Apple ][+, had 6 ROM chips of 2k each, or 12k total from 0xD000-0xFFFF. Also, if you booted a DOS 3.3 or ProDOS floppy, it would load somewhere from 0x9000-0xBFFF, I believe; otherwise, this was free RAM for your use. Finally AppleSoft BASIC programs sat at 0x0800 on up, but watch out for using the HGR command, or you could clobber the end of your program! 😬 Not sure what was at 0xC800-0xC8FF, though; maybe more free RAM?
Very cool to see for someone who did not well with the language back in the day. The things I didn't grasp under 'time intensity' I find I am able to 'casually'. So I will BNE LOOP like it's 1989.
Yep. And as I've said in comments to other people, don't be hard on yourself - the amount of context it takes to understand assembly language is actually quite a bit.
We should have been taught this stuff in school in the early 80s We were totally ripped off. Didn’t even have computers in all of Highschool. Had one single pet in elementary school. In the entire school !
It would have been great, huh! That said I recall not many people had the expertise to effectively teach this sort of thing back then. Certainly your average high school teacher wouldn't have known back then how to program in assembly language.
Tea Leaves no but we should have been learning the basics. Of hardware and software. Computer sci 101 in Fürst year university I took. It was a bird course. No programming. Surely they could have had someone come once a week to teach BASIC on a bunch of pets. Or even if we had to just write it on paper and have it in. That’s what I would do with snippets I’d find somehow. And when I got a chance I’d enter it on the single pet we had in school. Grade 4. 1983. Cheers. Thx for your content.
Woody Woodlstein I remember first entering the built in Apple assembler and doing a hex dump in high school in the 80s ... I thought I broke the computer! They were teaching us BASIC, but that was the start of my love for Assembly!
Tea Leaves that’s exactly what I did. There was nothing in my school library on computers. And coding. Whatever I could get my hands on. But I should have went to my city library. I should have put an ad in the paper looking for ANYONE who could help me learn in my town.
@@TeaLeavesProgramming Impressive! I used to type a HEX machine codes (i8080) from magazine to get first tools - $ASSM and $EDIT :D I can imagine how modern OSes could run at speed of light if they were written entirely in Assembly.
BASIC tended to be slow on most microcomputers because it was implemented as an interpreter rather than compiler. On the other hand, being implemented as an interpreter did make the computer *significantly* more accessible. Speaking of slow... I do remember BASIC being especially slow on the TI-99/4. Considering the specifications of the hardware (16-bit CPU clocked at 3MHz -- compared to 8-bit CPU clocked somewhere between 1MHz and 2MHz), with all other things being equal, one would've expected a BASIC program on the TI-99 to easily run circles around an equivalent BASIC program on most 8-bit micros of the time, NOT slower (noticeably so -- in some cases it seemed to be 4x to 10x slower). Many years later found out the reason -- the BASIC interpreter wasn't written in native code (as would've been typical on most micros of the day), but was implemented as a program that ran atop a byte-code interpreter.
@@TeaLeavesProgramming I did have the classic David Ahl books -- "BASIC Computer Games" and "More BASIC Computer Games" The "one-liners" and other short bits of code printed in the Beagle Brother catalogs were always amusing (obviously these would''ve been for the Apple ][). The hi-res resolution on the Apple ][ was 280x192 (monochrome, in colour it was 140x192) -- certainly higher resolution than the 128x48 pseudo-graphics of the TRS-80. On the other hand, I remember the the NTSC color artifacting was rather maddening, as well as the seemingly odd memory map for the graphics display. On topic of hi-res... always did find amusing the image of a Hires root beer can rendered in the Apple ][ hi-res graphics mode.
![Karel the Robot - A Lost Apple ][ Treasure Found](http://i.ytimg.com/vi/ZFvZZnySpuY/mqdefault.jpg)
![Karel the Robot - A Lost Apple ][ Treasure Found](/img/tr.png)
![Programming Like It's 1979: 6502 Assembly language on the Apple ][](http://i.ytimg.com/vi/PNOj6GTzfGY/mqdefault.jpg)
I modeled programs in BASIC, but used subroutines. Then I started to convert the subroutines to relocatable assembly routines. Over time, programs would become full assembly programs, and very fast. And since many of the routines were saved as pieces, I could graft together a new program from the saved routines, like a library, in a simple BASIC wrapper.
What a time! Thanks for the awesome video!
My first paid programming job was 6502 on Apple //e. This was a fun trip down memory lane. While programming in assembler seems tedious, I found it actually kind of calming in a meditative way. When a complex routine finally worked, the rush was exhilarating. It felt like successfully building the Eiffel Tower out of LEGO.
Great analogy!
I like that analogy. I feel the same way when getting something complex to work.
Not as low level but similar in terms of being close to the hardware and your analogy of getting something complex to work... Try writing a 3D Graphics Application to produce 3D Procedural Terrain Generation using Vulkan writting in C/C++... now that's tough! OpenGL and DirectX is still a challenge but Vulkan has a much steeper learning curve! Next up is writing an NES 6502 Emulator along with the rest of the NES's hardware components in C++. After that finish with making an actual 8, 16 or 32 bit CPU from logic gates in Logisim, then translate that into HDL or VHDL... My next project when I can save a few extra bucks would be to buy some breadboard kits and follow along with Ben Eater on his 8 bit bread board CPU... I completely know what you mean by getting something complex to work and the success of doing it is like having the Hoover Damn built!
Though I'm Atari 800 fan, all the "weirdness" about Apple "hi res" graphics speaks about the brilliance and genius of Woz. He managed to take what is basically a monochrome signal and exploit the NTSC timing to get 6 colors out of it using a minimal number of chips. The dude is the level beyond next level.
It's reasonable to think of the Apple II as a video generator with a computer attached to it, rather than the reverse.
Good Presentation! I produce games on the Apple ][. Apple ][ hires graphics have peculiarities for sure, but once you have routines that keep track of the memory lookup tables and bitmap shifts, you never have to think about them again. I wrote a whole arcade game engine last year for my first game Alien Downpour. Once the engine was done, the game came together quick. I wrote my current game OidZone using the game engine in about a month. I started programming using Merlin Pro 2.41 running in the applewin emulator. Last year I moved over to using the PC using a text editor with Merlin32 to assemble.
Cool.
Your games look nice.
Wish i had learnt this back in the day. It seemed very mysterious to me at the time, seeing page after page of DATA 169,0,192,32...etc etc in computer magazine listings and having no clue what they did.
Bought myself a commodore PET some years ago and taught myself ML, still learning of course but having fun. I get a great sense of satisfaction when a small program actually works! These days with the advent of the internet, online tools, windows based assembly programs, emulators and videos such as yours make it so much easier that I finally get to pull down the curtain on ML. Thanks!
Great video, very well done. I code in Intel assembly and found this to be so interesting. Thanks for the post!
Very interesting, thanks.
I never owned an Apple II, but i have 'dabbled' with 6502 code, initially on a Commodore PET, and later on a BBC Micro.
I did actually submit a MC program to one of the computer mags of that era.
It was a program to convert any number from any base to any other base (e.g. binary to octal etc). I still own some BBC machines, but these days I just use them for games etc.
I've tried some coding on the Apple II emulator (Virtual II) on my Mac, and it all works well. Thanks for the nostalgia trip.
I have never seen a BBC Micro in person but it's a legendary machine. Thanks for the comment!
It's actualy "technically" faster to use self-modifying code. The tightest loop is roughtly
LDA #value
LDX #0
ptr STA $0000,x
INX
BCC ptr
INC ptr+2
BCC ptr
now... you need to initialize ptr + 1 and ptr + 2 ... and you need to check finishing conditions ... but you can add those.
Ohh look who's here, my other head!
@@bahorized my other car
I often feel like it was a shame that I was too young to understand this stuff when it was relevant (cut my teeth in AppleSoft BASIC as a kid). Once I was old enough to grasp assembler, the Apple II was no longer relevant (and nostalgia hadn't yet kicked in like it is now).
Of course back then you really had no way of actually learning this stuff unless you were lucky enough to stumble across the right book, and knew adults who could steer you towards them. Most adults I had access to at the time were really not on the level to do that.
Agreed - don't be too hard on yourself, it actually takes quite a lot of context to spin up on this.
I think when you were talking about LSB and MSB, you meant "byte" instead of "bit". I used to program in Z-80 and 8080 back in the 70s and 80s, on the TRS-80 model I computer. Great fun! You do a nice presentation. I learned a lot.
You're surely right, Anton - I misspoke. Thanks for the correction!
Yep, Little Endian vs Big Endian.
One of my favorite Apple ][ programs/utilities was a BASIC-to-Assembly transcoder. Everything runs much faster in machine language!
Did this transcoder have any limitations regarding usable BASIC commands or size of the BASIC program?
@Tea Leaves
One question. In 9:05 or line number 14 to 16 you load with the LDA instruction 16 Bit values in a 8 bit accumulator register. Why does this work?
All your 3 variables GRAPH, HIRES and PGONE you set up with the EQU instruction are 16 bit wide (4 Hex values), so why does your command "LDA GRAPH" etc. work? Did i miss something?
The addressing mode being used there is called “absolute”. The 16 bit value following the op code is used as the address to load ann eight bit value. So it’s not saying load the HIRES value into the accumulator, but rather load, the eight bit value at the memory location specified by HIRES.
@@TeaLeavesProgramming Thank you for your answer.
Very cool to see this and bring back memories. When I was 16 I wrote a hybrid program, which was common of the day, that allowed me to edit the Bard’s Tale character disks. I released it as shareware at the time. I used basic for logic and user interface and ML routines for low level disks i/o. As an avid subscriber to Call A.P.P.L.E. And Nibble magazines I was always amazed at the versatility on the apple ][. I think the most impressive thing I had seen in during those years was the nibble article on creating a sound sampler using the audio port. It was pure magic on a machine just not made to be an audio/graphics killer app.
That's awesome! I could have used your program when I tried to play Bard's Tale.
6:45 The exact reason is that store instructions on 6502 perform the store to the memory twice while the load instructions perform the load once. Go to visual6502 (www.visual6502.org/) to see this quirk in action. This means any device wired to trigger by stores would get triggered twice per write instruction. Therefore they decided to trigger the hardware by reads for precisely the same reason as why the hires screen is interlaced: to save chips.
Fascinating. Is this also true for stores to the zero page?
Pardon the rookie question, since I'm fairly new to programming on the assembly level. And the vast majority of my experience with the 6502 is with the Commodore machines.
But are soft switches like a really simple version of os calls or built-in macros? Because they kind of seem close to it, only turned on in a really weird way.
Not a rookie question at all, they're not intuitive. If you squint really hard you could view them that way, but they're even less sophisticated. A "soft switch" generally means "do anything to this location in memory and it does something." Notably, this means you can turn on graphics mode by writing a value to a memory location - but sometimes you can also do it just by READING that memory location. Sometimes reading vs writing a soft switch will do different things. The documentation always specifies whether you have to read, write, or if either works.
I don't know where the term originated, but you can find Apple specific information in the Apple II Technical Reference Manual, which says:
"The devices which decide between the various video modes, pages, and mixes are called 'soft switches'. They are switches because they have two positions (for example: on or off, text or graphics) and they are called 'soft' because they are controlled by the software of the computer."
I don't know if the term "soft switches' was ever used outside of an Apple II context.
It's strange that the 6502 LDA instruction altered flags, it makes it harder to implement tight IF/ELSE statements.
Please, do more apple assembly videos! Awesome!
You'll like this week's video on Robot War!
Since A already contained $00, you could have used TAY (transfer A to Y) on line 13, which would only have taken one byte and two cycles as opposed to two bytes and three cycles.
Also, there was no need to increase LSB each time around the loop; you could have just increased Y with INY, which takes only 2 cycles as opposed to 5 .....
Thanks for the suggestions! One of the challenges of programming generally and assembly specifically is knowing when it's worth trading off readability for speed. I certainly wasn't trying for optimal efficiency here, but it would be interesting to know how much faster the changes you suggest would have made the program. Try it out and let us know!
@@peterb3398 In a project of mine, I've used a neat trick where I have to copy 4 bytes , and I also incidentally need a 4 at the end (it's part of a chain-plotting routine. 4 is the plot mode for move; and whenever we do a move, we want to save the co-ordinates so we can close the path later). So my code is like this:
.copy_co-ords LDX #0
.copy_co1 LDA screenX, X
STA lastmoveX, X
INX
CPX #4
BNE copy_co1
TXA \ here X=4
STA plotmode \ 4 is move
JMP plot_point \ it will have its own RTS
Now whenever one of the co-ordinates in the chain has a "move" instruction, we copy the co-ordinates. There are two bytes for the X co-ordinate and two bytes for the Y co-ordinate, units first; and when the copying is done, we have a handy four in our X register to set the plot mode!
There are more cunning stunts later. If we have a close instruction immediately following a move instruction, we want to use that as shorthand to draw a rectangle:
.close LDA plotmode
CMP #4
BNE close1
INC plotmode \ 5 is draw line
\ boring instructions to draw lines to 3 intermediate points missed out
JMP plot_point
.close1 JSR plot_point \ plotmode must already be draw
LDX #0
.close2 LDA lastmoveX, X
STA screenX, X
INX
CPX #4
BNE close2
JMP plot_point
Plot mode 5 is "draw line". If the plot mode is 4, we know the last instruction must have been "move"; so we just use an INC instruction to change it to 5, draw round the intermediate points (using a modified version of the plot_point code that never gets called from anywhere else, so it's just inserted inline. It doesn't take up enough space to spoil any relative branches around it) and finally, copy back the last moved-to point before we return to the calling routine via plot_point. (A JSR instruction immediately followed by an RTS can be replaced with a JMP instruction, which is a "one-way" jump that does not save an address on the stack; so when we hit the final RTS of that subroutine, the address on top of the stack points to the instruction immediately after the JSR that called this subroutine.)
This is all going to be Open Sourced eventually, so I am commenting my code for the benefit of future hackers :)
Wait, is it Kevin Mitnick ?
Nope!
There is no need to LDA #PATT each time through the loop. Instead, you could INY and BNE LOOP. When this branch falls through, you could INC MSB, LDX MSB, CPX #$40, and BNE LOOP. This will run about 30% faster and take less progmem.
Thanks for the suggestions.
Would you do some videos on x64 Assembly? Awesome content
I don't know a lot about x64 assembly, actually, but I'll consider it!
I'll try to be brief. I wrote the code in Applesoft Basic to play Qubic, or 3D Tic-tac-toe. It's played in a 4x4x4 format. There are 76 winning patterns of 4 in a row pieces. The player entered the level-row-column to make a move. E.G. square 111 was level 1, lower left space. My logic then would make a move (after seeing if the player had won). This reply could take as much as 45-60 seconds. I recoded the program logic in machine code, not assembly (technically the result would be similar). The new program would reply before the players finger left the enter key. I sold one copy to a fellow at Applefest in Boston around 1978?
I'd have written this a little differently, for faster speed. Starting after you switched to HiRes mode:
LDX #$20
LDA #PATT
LOOP:
STA (LSB),Y
INY
BNE LOOP
INC MSB
DEX
BNE LOOP
BRK
Your way is not bad, but it does waste a lot of optimization that hurts both speed and memory use. Good video, though.
I was expecting him to type call -151 at 5:10 and use the mini-assembler. That's how I taught myself 6502 assembly as a ten-year-old.
Hi, Daniel! I actually walk through CALL -151, the monitor, and the mini-assembler in my previous video, ruclips.net/video/PNOj6GTzfGY/видео.html. So you're not alone!
Love it.
What emulator do you use?
Gerard Putter's "Virtual ]["
@@TeaLeavesProgramming Great thanks. I've also come across Commander X16 (github.com/commanderx16/x16-emulator) Retro computer project- it's like a Modern Apple/C64. Nice.
Well done, BOSS! ;-)
And computers were so expensive in the early 80s. There was no way my parents would shell out .
We did have a coleco vision. Which was amazing. But it didn’t have any development options. Like the Atari had apparently. Pretty sure that’s what mark zuck had as his first taste
It should be noted that 0x0000-0x00FF was RAM, but used for jump tables (I think), and 0x0100-0x01FF was the 6502 stack. Also, the Apple ][+, had 6 ROM chips of 2k each, or 12k total from 0xD000-0xFFFF. Also, if you booted a DOS 3.3 or ProDOS floppy, it would load somewhere from 0x9000-0xBFFF, I believe; otherwise, this was free RAM for your use. Finally AppleSoft BASIC programs sat at 0x0800 on up, but watch out for using the HGR command, or you could clobber the end of your program! 😬 Not sure what was at 0xC800-0xC8FF, though; maybe more free RAM?
Very cool to see for someone who did not well with the language back in the day. The things I didn't grasp under 'time intensity' I find I am able to 'casually'. So I will BNE LOOP like it's 1989.
Yep. And as I've said in comments to other people, don't be hard on yourself - the amount of context it takes to understand assembly language is actually quite a bit.
We should have been taught this stuff in school in the early 80s We were totally ripped off. Didn’t even have computers in all of Highschool. Had one single pet in elementary school. In the entire school !
It would have been great, huh! That said I recall not many people had the expertise to effectively teach this sort of thing back then. Certainly your average high school teacher wouldn't have known back then how to program in assembly language.
Tea Leaves no but we should have been learning the basics. Of hardware and software. Computer sci 101 in Fürst year university I took. It was a bird course. No programming.
Surely they could have had someone come once a week to teach BASIC on a bunch of pets. Or even if we had to just write it on paper and have it in.
That’s what I would do with snippets I’d find somehow. And when I got a chance I’d enter it on the single pet we had in school.
Grade 4. 1983.
Cheers. Thx for your content.
Tea Leaves better late than never !
Mid 40s. Lol.
The brain sure slows down at this age. Grrrrr.
Woody Woodlstein I remember first entering the built in Apple assembler and doing a hex dump in high school in the 80s ... I thought I broke the computer! They were teaching us BASIC, but that was the start of my love for Assembly!
Why? Even bad Assembly is faster than BASIC.
I'm personally VERY talented at writing bad assembly that's even slower than BASIC!
BASIC was the pyhton of its day. Slow as hell and everybody used it.
Raise your hand if you remember typing in BASIC games from listings in magazines.
Tea Leaves that’s exactly what I did.
There was nothing in my school library on computers. And coding.
Whatever I could get my hands on.
But I should have went to my city library.
I should have put an ad in the paper looking for ANYONE who could help me learn in my town.
@@TeaLeavesProgramming Impressive! I used to type a HEX machine codes (i8080) from magazine to get first tools - $ASSM and $EDIT :D I can imagine how modern OSes could run at speed of light if they were written entirely in Assembly.
BASIC tended to be slow on most microcomputers because it was implemented as an interpreter rather than compiler. On the other hand, being implemented as an interpreter did make the computer *significantly* more accessible.
Speaking of slow... I do remember BASIC being especially slow on the TI-99/4. Considering the specifications of the hardware (16-bit CPU clocked at 3MHz -- compared to 8-bit CPU clocked somewhere between 1MHz and 2MHz), with all other things being equal, one would've expected a BASIC program on the TI-99 to easily run circles around an equivalent BASIC program on most 8-bit micros of the time, NOT slower (noticeably so -- in some cases it seemed to be 4x to 10x slower). Many years later found out the reason -- the BASIC interpreter wasn't written in native code (as would've been typical on most micros of the day), but was implemented as a program that ran atop a byte-code interpreter.
@@TeaLeavesProgramming I did have the classic David Ahl books -- "BASIC Computer Games" and "More BASIC Computer Games"
The "one-liners" and other short bits of code printed in the Beagle Brother catalogs were always amusing (obviously these would''ve been for the Apple ][).
The hi-res resolution on the Apple ][ was 280x192 (monochrome, in colour it was 140x192) -- certainly higher resolution than the 128x48 pseudo-graphics of the TRS-80. On the other hand, I remember the the NTSC color artifacting was rather maddening, as well as the seemingly odd memory map for the graphics display.
On topic of hi-res... always did find amusing the image of a Hires root beer can rendered in the Apple ][ hi-res graphics mode.
Big endian is reversed, little endian is the normal logical way 😂
The future belongs to the 36-bit word loyalists.