I'm super excited to see you do this! I did days 3, 4, 5, 7, 8, 10, 11, 14, 16, 18, 22, 23, 24, and 25 in ZX BASIC on the Spectrum, always producing a visualization of some kind - I posted about each one on the AoC subreddit. Sometimes the code can even run on the low-end 16kB model! For speed where needed, I used the HiSoft BASIC compiler, which is really pretty good for making Z80 assembly code (not as good as hand-written, obviously), but surprisingly good and much less work. I also have a Spectrum Next, which makes running on real hardware a lot easier. Regarding day 5, when you have to hand-roll your data structures, I think it's actually easier to make them do unusual things. Until today, I'd only bothered to do a Spectrum version of Part 1 (as I thought that would make the nicest visualization), but to make sure I wasn't mistaken that Part 2 isn't really much different, I flipped the code to do part two - it was pretty straightforward to change my `pop` implementation to “pop the wrong way”. You can see it run here: ruclips.net/video/NkDp6qdQUJU/видео.html - as far as performance goes, since I wanted this to be a visualization, I had to _slow it down_. One other random thing, if you count cycles taken or bytes used, the IX and IY operations are often pretty poor choices. I rarely find myself wanting to use them. And if you use IY, you have to disable interrupts or use IM2. Myself, I like to be friends with the ROM. But, again, I'm really intrigued to see where you go.
that's some really cool work, I like your video :) And yes you're absolutely right about the ix and iy instructions. As for code size and performance: I found that register scheduling is often easier when I make use of these registers. On use of iy: for a while I thought I had been careful enough with my use of iy to avoid conflicting with the ROM, but I do have a story about interrupts to share in a future video XD. Spoiler alert: I discovered quite late that iy is used by the timer interrupt handler.
@@computingthedetails Glad you liked the video! I checked out your git commit history to see how you were getting on (I'm eager for that next video!) and I saw a comment on Day 13 that it had been a bit of a challenge. So of course, that made me curious and I whipped up a Spectrum BASIC version of my recursive solution (ruclips.net/video/oscWKb4IjZw/видео.html); seemed pretty natural. I didn't check out your code, but maybe you went for doing in a more linear fashion, which I think is a lot harder to keep straight in your head. BTW, like the videos for all my other ones, there are actually multiple versions, one on the Spectrum Next, one on a classic Spectrum, and one with the full cassette loading experience. For some of the other ones, there are also sped up videos for cases where it's a slog for the Spectrum to solve it. Some of them are kinda mundane, but some a pretty cool.
_"In the ZX Spectrum this is not an option. You have to load the whole file or none of the file."_ Not correct. Well, it's correct if you are using the loader provided by the ROM. However, it's perfectly possible to do processing while loading a file, you just need to implement your own loader. There were many games for the ZX Spectrum that did stuff on screen while they were loading data from the tape (a few of them even allowed you to play a minigame while loading). It's perfectly possible to do calculations on the data being loaded while loading more data, and discard already processed data. (Of course this isn't trivial to do. As mentioned, you need to implement your own loader code.)
I don't think the Z80 has a 16-bit adder, it's only got a 4-bit wide ALU. There are 16-bit and 8-bit add instructions but they use multiple cycles to perform the whole operation. I think there's also a 16-bit incrementer/decrementer for advancing the PC, stack operations etc.
This opens up all sorts of ideas. How about using obscure/unusual languages? Forth maybe? Just to be interesting, a Forth implementation on a Speccy. Or something modern but not designed for GP programming? Or have a look at some really exotic hardware? You wimped out using emulators 😅 but jolly entertaining and insightful!
@@rastislavzima didn't work with one, but at that times, data bus was all that matters (I did not said that I agree, it's just the way it was, or that way Pentium MMX was 64 bit processor)
The big problem I'd have with the Spectrum is the lack of a well-defined space bar. That would suck. The other problem would be storage - that tape drive is NOT elegant. It's a pity this machine was too early to benefit from the 3.5 inch floppy. As for the 48K... the Commodore 64, bless its memory, only had 39K booted up, although you could switch out the BASIC ROM and use that if you were happy to program entirely in machine code.
All those problems are easily solved. Either by using a later Spectrum with better keyboard, running in 48K mode, and an SD card adaptor, or just use a separate IDE on PC/Mac/Pi to write code, and an emulator to test on.
This is an interesting topic, I have a few different cassette decks, and the tape counters on them move at different rates. In particular there's two different categories: supply reel counters, and take-up reel counters. The numbers you get from them start off the same at the begging of the tape (of course), drift apart until you're about half way through the tape where they are wildly different, and then come back to being in sync by the end of the tape. I'm not sure which one is supposed to be the standard, but unfortunately it's not reliable between cassette decks. But yes, you're right, having a little index card with numbers on does make things easier. :)
@@computingthedetails You can also insert a medium frequency buzz in the middle of the data blocks and use the play/seek function if you have a later model tape player. This will however eat up minutes on the reel. I only had the one, more "modern", longer narrower style of tape decks though, so I could rely on the counter more.
Cool target ;) You made my day ;) I wonder how many tasks are really over BASIC limits (excluding time) I could do this on ZX81 but it lays in family home dungeon...
Thanks! Glad you enjoyed it. Certainly I could have done some of these tasks with BASIC alone. I think most of the tasks from day 7 are beyond what I could do in BASIC. Hopefully part 2 of this series will explain why, once I'm done making that video :) Day 9 was especially difficult to fit into 48k, but you'll probably have to wait until I make part 3 to see why :D
Good to see you were using an emulator in development. I was positively alarmed to think you were coding on that dreadful "key"board. Sinclair awfulness.
I'm super excited to see you do this! I did days 3, 4, 5, 7, 8, 10, 11, 14, 16, 18, 22, 23, 24, and 25 in ZX BASIC on the Spectrum, always producing a visualization of some kind - I posted about each one on the AoC subreddit. Sometimes the code can even run on the low-end 16kB model! For speed where needed, I used the HiSoft BASIC compiler, which is really pretty good for making Z80 assembly code (not as good as hand-written, obviously), but surprisingly good and much less work. I also have a Spectrum Next, which makes running on real hardware a lot easier.
Regarding day 5, when you have to hand-roll your data structures, I think it's actually easier to make them do unusual things. Until today, I'd only bothered to do a Spectrum version of Part 1 (as I thought that would make the nicest visualization), but to make sure I wasn't mistaken that Part 2 isn't really much different, I flipped the code to do part two - it was pretty straightforward to change my `pop` implementation to “pop the wrong way”. You can see it run here: ruclips.net/video/NkDp6qdQUJU/видео.html - as far as performance goes, since I wanted this to be a visualization, I had to _slow it down_.
One other random thing, if you count cycles taken or bytes used, the IX and IY operations are often pretty poor choices. I rarely find myself wanting to use them. And if you use IY, you have to disable interrupts or use IM2. Myself, I like to be friends with the ROM.
But, again, I'm really intrigued to see where you go.
that's some really cool work, I like your video :)
And yes you're absolutely right about the ix and iy instructions. As for code size and performance: I found that register scheduling is often easier when I make use of these registers. On use of iy: for a while I thought I had been careful enough with my use of iy to avoid conflicting with the ROM, but I do have a story about interrupts to share in a future video XD. Spoiler alert: I discovered quite late that iy is used by the timer interrupt handler.
@@computingthedetails Glad you liked the video!
I checked out your git commit history to see how you were getting on (I'm eager for that next video!) and I saw a comment on Day 13 that it had been a bit of a challenge. So of course, that made me curious and I whipped up a Spectrum BASIC version of my recursive solution (ruclips.net/video/oscWKb4IjZw/видео.html); seemed pretty natural. I didn't check out your code, but maybe you went for doing in a more linear fashion, which I think is a lot harder to keep straight in your head.
BTW, like the videos for all my other ones, there are actually multiple versions, one on the Spectrum Next, one on a classic Spectrum, and one with the full cassette loading experience. For some of the other ones, there are also sped up videos for cases where it's a slog for the Spectrum to solve it. Some of them are kinda mundane, but some a pretty cool.
_"In the ZX Spectrum this is not an option. You have to load the whole file or none of the file."_
Not correct. Well, it's correct if you are using the loader provided by the ROM. However, it's perfectly possible to do processing while loading a file, you just need to implement your own loader. There were many games for the ZX Spectrum that did stuff on screen while they were loading data from the tape (a few of them even allowed you to play a minigame while loading). It's perfectly possible to do calculations on the data being loaded while loading more data, and discard already processed data.
(Of course this isn't trivial to do. As mentioned, you need to implement your own loader code.)
ruclips.net/video/8o_dVHiuR_Q/видео.html
I learnt coding on a Spectrum - loved it.
This video is fantastic! Thank-you for all of your hard work 😊
I don't think the Z80 has a 16-bit adder, it's only got a 4-bit wide ALU. There are 16-bit and 8-bit add instructions but they use multiple cycles to perform the whole operation. I think there's also a 16-bit incrementer/decrementer for advancing the PC, stack operations etc.
This opens up all sorts of ideas. How about using obscure/unusual languages? Forth maybe? Just to be interesting, a Forth implementation on a Speccy. Or something modern but not designed for GP programming? Or have a look at some really exotic hardware?
You wimped out using emulators 😅 but jolly entertaining and insightful!
Or.... Forth on Jupiter Ace.
yeah like the C-ish python
Your insane. Love it! I did one problem on an arduino using Rust with nostd. Super fun trying to do it on weird hardware!
People mostly calling processors only for data bus. So Z80 is an 8-bit processor
So MC68008 is also 8-bit processor?
@@rastislavzima didn't work with one, but at that times, data bus was all that matters (I did not said that I agree, it's just the way it was, or that way Pentium MMX was 64 bit processor)
This is briliant. Good visuals as well!
Z80 assembly, eh? Now, that’s my kind of coder. Kudos!
i would like to see the rest of the aoc (advent of code) done
I'm working on the part 2 video now, I'm hoping to get all of 2022's advent done :)
Yeah, that's pretty brave! Well done :)
The big problem I'd have with the Spectrum is the lack of a well-defined space bar. That would suck. The other problem would be storage - that tape drive is NOT elegant. It's a pity this machine was too early to benefit from the 3.5 inch floppy.
As for the 48K... the Commodore 64, bless its memory, only had 39K booted up, although you could switch out the BASIC ROM and use that if you were happy to program entirely in machine code.
All those problems are easily solved. Either by using a later Spectrum with better keyboard, running in 48K mode, and an SD card adaptor, or just use a separate IDE on PC/Mac/Pi to write code, and an emulator to test on.
Does your tape player not have a ticker counter on it? Makes finding data blocks a lot easier.
This is an interesting topic, I have a few different cassette decks, and the tape counters on them move at different rates. In particular there's two different categories: supply reel counters, and take-up reel counters. The numbers you get from them start off the same at the begging of the tape (of course), drift apart until you're about half way through the tape where they are wildly different, and then come back to being in sync by the end of the tape. I'm not sure which one is supposed to be the standard, but unfortunately it's not reliable between cassette decks.
But yes, you're right, having a little index card with numbers on does make things easier. :)
@@computingthedetails You can also insert a medium frequency buzz in the middle of the data blocks and use the play/seek function if you have a later model tape player. This will however eat up minutes on the reel. I only had the one, more "modern", longer narrower style of tape decks though, so I could rely on the counter more.
Cool target ;) You made my day ;)
I wonder how many tasks are really over BASIC limits (excluding time)
I could do this on ZX81 but it lays in family home dungeon...
Thanks! Glad you enjoyed it. Certainly I could have done some of these tasks with BASIC alone. I think most of the tasks from day 7 are beyond what I could do in BASIC. Hopefully part 2 of this series will explain why, once I'm done making that video :)
Day 9 was especially difficult to fit into 48k, but you'll probably have to wait until I make part 3 to see why :D
You need a microdrive!
Good to see you were using an emulator in development. I was positively alarmed to think you were coding on that dreadful "key"board. Sinclair awfulness.
I got halfway through this and still none the wiser as to what this avent BS is about.