stepho

Get a copy of "Inside Atari DOS". Mr Google will point you to online copies or you buy a paper copy off ebay/craigslist/etc. This book explains the why's in great detail. It also adds in the actual code for how DOS 2.0S was implemented. If you really want to write your own DOS then stare at this code until you understand it - and then do your own version. Stepping through it with a debugger will also help. Adding subdirectories can get a bit hairy in the code. You need to add setCurrentDirect and getCurrentDirect routines. And every file open and directory list command needs to know about absolute addresses (eg /d1/d2/filename) vs relative filenames. eg filename (really ./filename), ../../../filename, ../d3/filename, etc Not really that hard but you need to dot all the i's and cross all the t's. An example for implementing the FAT filesystem for PC's (with subdirectories, timestamps and optional long filenames) has open source code available from http://elm-chan.org/fsw/ff/00index_e.html

Back in the day, it was common for BASIC programs to have a small machine code routine encoded as DATA statements. The BASIC program would read these and then store them in some free RAM. Or sometimes it would encode them as strings. The BASIC program would then write a custom display list that causes the machine code routine to be called. The routine would typically change the colour palette and exit quickly (ie short and sweet). It was a pain in the backside to have to do hand assembly into numbers and then add these as DATA statements but it was all doable from BASIC and a bit of determination. I learnt this technique circa 1984 from reading magazines. For the readers who didn't want to handle assembly, the articles would just say "change the 78 in position 5 and the 92 in position 10 to the colours of your choice". Easy! But as you said, practically all platforms of the day did similar to get around limitations.

My guess is that it was written (or last updated) when Windows 7 was replacing Vista. The code probably looks for evidence of Windows 7 and anything else counts as Vista. Windows 10 is not Windows 7, so it counts as Vista. Developers used the same cheap scheme when Windows 3 replaced Windows 2. So when Windows 95 came along we got programs warning us that they wouldn't work on our Windows 2 PC - even though we were running Windows 95. Some things never change - sigh.

It's been a few decades since I've dabbled in Forth but I remember a few things to be aware of: - most things go on the stack - which is usually a simulated stack, not the CPU's hardware stack. - Forth was often used to write assemblers for new machines. - Forth's threaded nature allowed mixing of purely interpreted code with code that was compiled. It even allowed you to replace a previously compiled subroutine with new script code and the other compiled code would automatically call the new script instead of the old compiled subroutine. It did this by each call checking a table before calling the script interpreter or call the complied version. This table checkup is of course expensive but your new language could skip that (or make it optional). The compiled form still uses the simulated stack for variables, so it may or may not be fast enough for a kernel if it skips the table check.

Not sure how replacing 8 bit graphics with 8 bit ASCII characters saves memory.

No-one else answered, so I'll give it a shot - even though my hardware skills are a bit on the vague side. Q1 Lines that cross with no circles do not touch each other. Some designers used a loop that look a bit like a bridge for the same thing. Lines that cross with circles are a physical connection. At the bottom of the vertical lines there are resistors and at the left of the horizontal line there is another resistor. These connections and resistors form a wired AND (or perhaps a wired OR - my brain is a bit fuzzy at the moment). Q2 The AUC0/1 registers are made from flip-flops. These flip flops had both 0 and 1 outputs - of which exactly 1 would be active at any given time. The 2 outputs are the 0 and 1 outputs of each flip-flop. Q3 Yes, they are transistors. When the centre connection is active then the left and right legs are effectively connected together. They act pretty much like relays do (gross simplification). See https://en.wikipedia.org/wiki/MOSFET Q4 Hand drawn circuits like this were made using a plastic template sheet with lots of standard component shape cut out of it. The designer would place the cut out over the work, stick his pen in and run it around the hole. If you needed more inputs than would fit on the standard shape then you added wings. The exact form of the wings was more of an individual style thing. Q5 I agree with you that on sheet 4 of 5 a 5-bit "AUDIO NOISE GEN." polynomial feeds into an unnamed 4-bit polynomial counter. Your assumption seems reasonable to me but I'm further out of my comfort zone here.

I still don't see the benefit for the 2600 The ZX81 doesn't have a true hires graphics mode, so anything that displays better than block graphics is good (in this case, by displaying the top lines of ASCII characters with a very impressive technique). The 2600 has a low res background that can't directly show ASCII characters. If it did show ASCII characters it would be by transforming the ASCII characters into background graphics. So we gain no benefit by using ASCII. Likewise for using ASCII characters in player/missile graphics. The ASCII characters take up 8-bits each. The final display is also 8-bits - except not all combinations can be displayed. So again, no benefit. Or have I missed something?

I made a slight mistake. The table is mostly a barrel shifter but I was wrong about the new bit (I didn't spot check enough values). The new bit (and the entire table) is just a table to implement CRC8. My guess is that the DPC+ does this job and that the table was just a hangover from the Pitfall-I code. It's quite common for professional programmers to disable something but to forget to remove it altogether, so it doesn't surprise me that its presence or absence makes no difference. Quite possibly it was temporarily removed for the prototype but they accidently forgot to make the change permanent. This is why I push so hard at my current job to make all release procedures totally automated and repeatable - but automated release procedures wasn't a big thing then back then.

If I understand the ZX-81 technique right, they are displaying only the top row of pixels from each row of ASCII characters to get a much higher resolution than normally available (albeit with restrictions). But since the 2600 doesn't have ASCII characters, I don't see how this relates to the 2600.

Just some generic things to look for... 1. Jumping to the subroutine takes a few cycles. Returning also takes a few cycles. You said it is in the vertical blank code but is it time sensitive? 2. Storing the return address takes a few bytes of stack. Is the stack big enough? 3. Some bank switching schemes trigger off subroutine calls (ie when you write/read the return address in the first few elements of the stack).

The 256 bytes at the end are not random. They are a simple barrel shifter where each value is the previous entry shifted left by 1 bit and the top bit inverted and feedback to be the new low bit. eg 1 $95 = b10010101 is followed by $2b = b00101010 eg 2 $01 = b00000001 is followed by $03 = b00000011 In pseudocode they are accessed as: new_value = table[old_value]

The end address or the size is off by one. Should be one of the following: Segment 1: Load:A000 End:A0FB Size:00FC Segment 1: Load:A000 End:A0FA Size:00FB

The obvious one is that if it doesn't get fed then it should weaken and eventually die. Weakening can be shown by fading towards white (green?). Dying can be something like collapsing into a small pile of ash or turning into a ghost and floating upwards. Need a way to get food. Either throw food towards it or maneuverer it towards food. Perhaps solve the occasional puzzle to get food (seems to be a thing with octopi in research labs to open jars to get a tasty crab). Perhaps add a need for exercise.

That's the 90/90 rule: The first 90% of the code takes 90% of the effort and the remaining 10% of the code takes 90% of the effort.

And another variation if the words seem too fussy (inspired by the simplicity of the "bb" Batari logo).

If you like the CD logo, then perhaps try the dithered version.

The vertical stripe in the U lined up nicely with the split between the 2 lower cushions. Was that intentional? Anyway, I played a bit with making the "couch" letters become the back cushions by making the lower cushions smaller and extending the back cushions down a bit.

Much appreciated. It's clear, concise and comprehensive - an excellent example of good documentation.

The black and white logo by Thomas looks good but these old eyes find it hard to differentiate the words from the line-art. So I edited them to fill in the cushions to make them a bit more solid to my eyes. grey fill-in monochrome fill-in brown fill-in monochrome dithered original Probably only the monochrome ones will work on an actual VCS.

Thanks for your work. Can we download it as a PDF file?

Netbooks have tiny screen, tiny keyboards and tiny mushpads. I used them for many years when travelling overseas but you really need to love tiny to be happy with them. I still use one occasionally as a serial terminal emulator for connecting to various bits of equipment and as a datalogger - where its small size is good. Second hand laptops are cheap and have much nicer sized keyboards, screens, etc.

What if occasionally a bomb would come down? - complete with sparkly fuse. If missed then it makes a bigger hole than normal - boom! If you catch it then something nasty happens (you die? or maybe lose a lot of points?) But if you can hit it from the side then it spins harmlessly off to the side - possibly with bonus points.

Break out from the brick's point of view - nice!

ilmenit, I think you missed the case labels in the first switch. Case 3 gives d=2 and case 2 gives d=3, which means d=c doesn't work for c==2 or c==3 . Which makes the second switch code functionally correct. The 2nd switch minimises the jumps required (notice the missing breaks) but would give interesting results if d was a pointer to a register (even worse if it is a write only register). I'm too lazy to evaluate code size and execution time. Harry, Perhaps rename files as: Optimizing_cc65_Code-part-1.txt Optimizing_cc65_Code-part-2.txt etc

Stacked Pokeys might have heat issues and current draw issues. As Rybags said, it might be interesting to use a single new CPU (AVR or ARM) to emulate a bunch of them. To the bus it would only be driving a single chip instead of many but could use the address space of the many. Does mean that the many emulated Pokey outputs would be merged to 1 or 2 physical outputs. I assume some of the voices would change slowly - eg bass lines. Which lessens the CPU overhead a little. Some voices might even be continuous rumble (eg engine noise on car/plane simulator) which would have no CPU overhead after it is set-up.