DeathShadow Site

[durango_d]

I visited your DS site last night, you dont talk much about that part of your hobbies and especially your js library. 

I was curious why you decided on pack man style game and not something else from that era, maybe centipede, astroids (one of my favs) i used to watch the bolders go to pieces as i shot them and wonder how that was done.  It was so cool how it would go all the way down to the very pixel it seemed when you kept shooting it, of course then i didnt know what a pixel was but i knew there were little lights in the screen somehow.

[Jason Knight]

Honestly I've been too sick and too busy working on paying stuff for those hobbyist interests for a few years. Hence why deathshadow.com is more of an afterthought / web rot relic at this point.

When it comes to the JS library (elementals.js) there's a version 4 waiting in the wings where all I need to do is write the usage examples, but most of it is already out of date now that many things it was created to do are native to JavaScript. Realistically for 90%+ of deployments now the only things I would actually use/need from it on a regular bases is the make and ajax stuff.

I've honestly been thinking about just deep-sixing that project altogether and labeling it a failure. As Jobs often said, you have to fail a lot before you succeed.

There's also a cousin project that might simply supplant it. I'm not willing to give a lot of details at this point as it directly conflicts with my normal advice on a topic... but I'm aiming for a January or February preview with a 1.0 full release sometime around March.

In terms of the retrogaming, I chose Pac-Man for a variety of reasons.

1) the tile system of the original game translated acceptably to the undocumented / non-standard video mode I chose.

2) the sprites were nice and large (15x16 in a 8 byte x 16 byte container), so the 3/8ths reduction gave me 5x5 pixel sprites in a 3 x 5 byte container. If the same reduction were applied to a game like centipede, I'd have to try to draw the shrooms as 2px x 3px... not exactly viable.

3) The portrait aspect of the game meant a lower memory footprint. Video RAM is slow and the video mode I chose has no "paging". As such I have to render everything to a backbuffer in system memory, then copy only what has been changed to the display.  By using 96 pixels -- 48 bytes width -- as the backbuffer size I was able to make row offset calculations faster as well by using shifts instead of multiple.

8088 multiplies are slow, measuring 150 clocks and upwards. If I had to do that for every video offset there's now way an original PC -- much less the slower PCJr -- could keep up.

Hence I use:

Code: [Select]

  mov  ax, row
  shl  ax, 1 ; row * 2
  shl  ax, 1 ; row * 4
  shl  ax, 1 ; row * 8
  shl  ax, 1 ; row * 16
  mov bx, ax
  shl  ax, 1 ; row * 32
  add ax, bx ; * 32 + * 16 = * 48

Sadly the 8088/8086 has no shift by immediate, and setting CL imm8 and shift by CL takes longer than just doing the four shifts manually.

to put that in terms mere mortals might grasp, in 1980's x86 assembler, this translated to C syntax

offset = (row >> 4) + (row >> 5);

is faster than:

offset = row * 48;

Despite being more code. You will see this in C code of the era for calculating VGA 320px wide graphics:

offset = (row >> + (row >> 6);

Which I have a sneaky trick for in ASM: (stuff after semi-colons are comments, same as // in C/JS/PHP)

Code: [Select]

  xor  ax, ax ; set ax to zero
  mov  al, row
  xchg  al, ah ; swap low and high bytes, AX now == row * 256
  mov  bx, ax ; bx === row * 256
  shr  ax, 1  ; ax === row * 128
  shr  ax, 1 ; ax === row * 64
  add ax, bx ; row * 64 + row * 256 === row * 320!

Which even on 286 class machines is faster than doing offset = row * 320; The trick here is that an exchange of AX's lower 8 bits (AL) and higher 8 bits (AH) is around 48 clocks faster than a shift by 8. Then we only need to shift >> 2 instead of << 6, further adding time savings.

There are other techniques like using lookup tables, but that wasn't viable for this project as I also wanted to keep it 256k memory footprint-friendly with DOS loaded. There is a version "in the works" in pure assembly that is 128k friendly that I'm hoping to make a 32k ROM for the PCJr out of. Said version basically has to self-decompress itself into RAM from the ROM.

Basically even the math of the game influenced the decision.

4) It was the best third party documented game. Pac Man was so popular in its time there are hundreds of books on the topic, and many online breakdowns. In particular the "Pac-Man Dossier" provided a lot of insight into the game logic WITHOUT my having to look at the original Z80 source code.

As such Paku Paku is a "clean room" implementation. The sprites I drew by hand myself. There is NO code from the original or even coding techniques related to the original involved. As gameplay mechanics were ruled NOT trademark or copyright protected, it's legally "free and clear". They can't touch me "legally"

It's also why I had to leave the cutscene animations out.

I do have two other games "in the works" -- that have been so for around a decade, that I still pick away at in my spare time. One is a space shooter, here's the tile sheet for that:



the other is a realtime rogue-like fantasy piece. Kind of like a mix between diablo and the old Atari 2600 "adventure". The sprites are mostly done for that one as well.



The hard part being turning those into "coded sprites".

Coded sprites is a technique by which you literally turn each and every sprite into optimized machine language that "draws itself". Instead of having a copy of the image in your variable space, it's literals in the code.

For example the cherry from Paku Paku as a coded sprite reads:

Code: [Select]

cherry:
mov  [di + 1], WORD 0x6006
mov  [di + 49], BYTE 0x66
mov  [di + 96], WORD 0x06C4
mov  [di + 144], WORD 0xC444
mov  [di + 193], BYTE 0x44
ret

This way the code only needs to stream from the code segment.

So instead of:

load code, load data, write data, update pointers

It's

load code, write data

This can be even faster because if you have transparency areas where you're NOT writing to, a data based sprite still has to store, compare, and copy those bytes. You might even have to have a second copy that acts as a "mask". You have a 3 byte by 5 byte sprite, that can be up to 60 memory operations at a minimum of four bytes per clock. Hard-coded as assembly it's 5 to 10 data memory writes and about the same amount of code reads.  The only real overhead being the offset calculation.

Which is probably greek if you don't know machine language...

[durango_d]

I used to know some of that stuff, i took fortran and assembly at ITT tech back in the 80's but if you dont use it you forget it.   It all looks familar but thats about all.   

So you had mentioned windows 3.1 before, do you still have a 3.1 original machine.  I had one up until about 15 years ago and i tossed it, i was moving and had to leave stuff behind.   It still ran but the display was fading fast.   I suppose anyone today with a 3.1 machine with a whopping 100MB hard drive would be paid a good bit of money for it.   

I do wish keyboards today would last as long as those old ones did.  This weekend i took all the keys off my gaming keyboard and cleaned under them... it was gross man after 6 years lol.....    But 3 of the key dont even have the letters on them anymore.  Those old keyboards were like old cars, built to last...

I still have some old 3.5 inch discs somewhere with some  3.1 games on them, and i have 1   5.25 inch floppy that i just keep in a old box to show my kids the way it used to be done.

I think i remember space shooter or the game like it,  you just move back and forth as the ships come down from above.    i still think astroids was amazing for its time, all the rolling and spinning of the astroids and the ship which if i remember was not much more than a colored in "A"  and the movements if you remember were cool when you bounced off stuff,  advanced code for its time in gaming.    Im sure some people had better code in the private sector but didnt say much about it i guess.   

My kids still cant believe when i tell them i had the chance to invest in the ground floor of MS but i didnt, who knew it was gonna bloom like it did.  I still remember when email came out, i thought, big deal ill never use it...   who knew..... well i guess they did huh..

[Jason Knight]

So you had mentioned windows 3.1 before, do you still have a 3.1 original machine.

As everything I'd run under windows 3.1 runs pretty much flawless under 9x, I've got a Win 98SE rig.

AMD 5x86-133 (fits a 486 socket) "overclocked" to 150mhz. It's technically NOT an overclock as it's within the design spec, but it's not something they advertised because a lot of 486 motherboards didn't support the real DX50 with its 50mhz base clock. The vast magority of machines could only support 25 or 33mhz, and in some cases 40mhz. Thus it was most common for these chips to go 133 (33x4) or 120 (40x3) or 100 (25x4).. but it does support the 3x modifier as well to push a 50mhz base clock to 150mhz.

Was one of the first CPU's to ever come with a heatsink and fan in the box instead of as a separate purchase.

It's funny though, as 3x 40mhz for 120mhz CPU clock was often faster than 4x33mhz at 133mhz CPU because of the faster data bus. At 133 it was roughly equal to a pentium 75. At 150mhz 3x50, it gives a Pentium 90 a run for its money... and is even faster in some cases. For example Diablo REALLY needs a pentium 120 to be enjoyable, but you can run it on a AMD 5x86 at 150mhz quite reasonably despite the huge IPC disparity.

The mobo for that machine in question:


486 class board, but nice because it has PCI, supports large denisity EDO memory, has two 32 bit IDE ports and PS/2 mouse built in (the five pin connector near the keyboard, takes a dongle), etc, etc.

That's 128 megs of 32 bit EDO memory sitting in there. It's comedy watching it start up trying to count up to that... and the BIOS has no memory test skip. Power on the machine, go get coffee... at Dunkins... the next town over... and take your time.

It's also a bit amazing for the time as it has half a megabyte of SRAM cache for the CPU. Compared to normal 486 boards that had either 64 or 128k of SRAM, the massive cache nets you around another 10% performance in many tasks.

I paired it with a PCI voodoo 2 and a Trident 4000 card.

I suppose anyone today with a 3.1 machine with a whopping 100MB hard drive would be paid a good bit of money for it.

You'd be surprised. Since 9x is basically fully 3.1 compatible the window to hardware is a lot bigger. Fans also tend to make machines that use compact-flash to replace the aging hard drives.

Even my tired old Tandy 1000SX is booting DOS 6.22 off a 128mb CF card, via an XT-IDE controller.

The XT-IDE project is tons of fun, I ordered mine as a kit in the form of the version 3, so I had to solder everything onto the board.

The IDE / PATA interface -- at least in its original incarnation -- is something of a joke as apart from having only 3 address lines (so you needed an encoder to sit between the plug and the bus to decode addresses) it was otherwise a direct mapping of the 16 bit ISA bus with all 16 data lines. Quite literally apart from an address decoder, all the wires from the drive went straight to the system bus. It's kind of brilliant as a little software on the CPU to give directions, a hold line to tell the CPU "hang on, I'm writing to memory" and putting the drive controller on the drive itself, and boom, the controller card in the machine was really simple.

The problem is on old PC/XT class systems you don't have a 16 bit bus, you have a 8 bit bus.

As such to use conventional 16 bit IDE drives on a PC or XT class machine (8088 / 8086) you need the controller to buffer the results from the drive. The controller wants to read 16 bits, you have to tell it "hold on", have an expansion card do the two reads required, then output them to the drive. Same process for a write where the disk's board will try to write 16 bits to memory, and your controller has to cache that and write it out in two operations.

Hence the XT-IDE controller was born. Laugh is in some cases because of the ability to buffer and the more modern software written for it, and by switching the drive to "polling" instead of "bus mastering" mode, it's possible for the XT-IDE to be faster than flat IDE in some 286 class machines. Mostly that's not so much the hardware's fault, as that of poorly written BIOS.

Which is why there's a version of the XT-IDE BIOS you can burn to ROM and use on 286's. Uses the normal hardware, but speeds things up just because the code and methodology isn't shite.

Even so, even without optimizations a modern CF card -- which itself is just a IDE device with a different plug -- will run circles around period correct hard drives. (no seek times). Basically, it's SSD's for vintage PC's.

Though I have gotten a 16 gig SATA SSD to recognize on XT-IDE in my T1k via a SATA to PATA adapter. The only issue is that there's no OS I can run on it that will recognize a Hard Drive that large.

I do wish keyboards today would last as long as those old ones did.  This weekend i took all the keys off my gaming keyboard and cleaned under them... it was gross man after 6 years lol.....    But 3 of the key dont even have the letters on them anymore.  Those old keyboards were like old cars, built to last...

You can still get decent keys, but yeah... what these keyboards ship with is junk. The "Aurealor Roamer" I have on my media center came with some lousy painted keys that yeah, you can wear the text right off of, but that's why I suggest double-shot aftermarket keys. For a reasonable price off of e-bay you can usually grab a full set for around $15 or less. So long as the keyboard in question uses cherry-style switches -- so that includes Gateron, outemu, etc -- they'll fit as it's pretty well standardized.

I actually often order three or four sets at a time to do custom colour layouts... for fun, for friends, and even for profit. You take a cheap-ass mechanical keyboard, replace the caps with decent stuff, add some of the aftermarket rubber o-rings to soften how they bottom-out, and you're good to go.

I still have some old 3.5 inch discs somewhere with some  3.1 games on them, and i have 1   5.25 inch floppy that i just keep in a old box to show my kids the way it used to be done.

You'd laugh at my collection -- the MAC SE that can only read their proprietary 800k 3.5" format, the Commodore 64 with TWO working 5.25" floppy drives, The Coco 1 and Coco 3 with their 160k single sided floppies... even my Tandy 1000 and PCJr only supports 360k 5.25" floppies.

Which is part of where that AMD5x86 win9x box comes into play. XP/later really hates or even outright doesn't support low density floppies well if at all. Some newer motherboards even if they have floppy connectors don't support 5.25"... so that 98SE box serves double duty for retrogaming/retrocomputing, and being a "middling machine"

Middling machines is the term for systems that are just old enough to support old media formats, but just new enough to talk to modern machines. I can get it on the LAN, I can get it to talk to my NAS... so I can use it to read my modern work and copy stuff to the old media. Because it has a parallel port, I can even use it to write to the Commodore 64 floppy drives using an adapter. (said drives being utterly incompatible with PC standard drive formats)

In fact in writing Paku Paku, most of the development was done in Flo's notepad 2, compiling the assembly with NASM native under Win7, but then the Turbo Pascal parts compiled and tested under DOSBox. To test it on the real iron, I uploaded to the NAS, downloaded to the 98 rig, then wrote to the old-school floppies.

I think i remember space shooter

I said "A space shooter" -- as in the generic category. Actual games of the genre includes Space Invaders, Galaxian, Galaga, Dorf, and the like.

i still think astroids was amazing for its time, all the rolling and spinning of the astroids and the ship which if i remember was not much more than a colored in "A"  and the movements if you remember were cool when you bounced off stuff,

It was also a vector graphics game, which means it ports poorly to raster graphics computers.

Instead of a constant sweep breaking the screen into separate pixels, a vector graphics display literally moves the electron stream from point to point, turning the beam on and off like a mechanical plotter. That's why the lines are smooth is there's no colour mask or scanlines involved. Each and every line is drawn directly, not as a bunch of separate pixels.

Which is why the Atari 2600 version is utter garbage:
https://www.youtube.com/watch?v=xP1Jtjk5vXY

And that's with twice the display resolution available that I'm using. Even the 5200 version which was a far more capable machine:
https://www.youtube.com/watch?v=KCL_GKJVS2Y

Is pretty shite...

In fact, pretty much all the computer ports are trash.
https://www.youtube.com/watch?v=UqghsUAzBsQ

At least until resolutions started climbing up past 320x200.

Vector graphics were short lived, and it's kind of a shame. All the games made with it -- Asteroids, Omega Race, Tempest, Star Wars, Star Trek -- had a very distinct look and feel. Porting any of them to raster displays was always junk regardless of platform.

I mean hell, look at the Star Trek Arcade Game:
https://www.youtube.com/watch?v=GuV-iqqrT4Y

And the Atari 5200 port:
https://www.youtube.com/watch?v=zgvo8OWhT34

Which is sad since the 5200 is from a purely hardware standpoint MORE capable than the Star Wars arcade. But the 5200 was limited by having to display on a TV using raster graphics.

Funny thing is, there was actually a game console -- that had it's own screen -- called the Vectrex that was all vector graphics.

[durango_d]

Wow look at all that pci you have....  I dont think any of that is pci-e either....   that brings back so many memories..  Yeah i remember the says having to remember to get both low density and high density disks as not all machines supported both...

this is my keyboard
https://www.newegg.com/black-corsair-k70-lux-cherry-mx-red/p/N82E16823816076?item=9SIA4RE8F65676

i wish i had gotten the RGB version as i am getting tired of the red...

My machine was built by me.   About 5 years ago i finally had enough saved up to order all the stuff i wanted to build a nice machine.  It came out pretty nice .  I was tempted to go with water cooled but me being old fashioned, water and elect dont mix... lol     I figured i was tempting fate.. Besides at that time they were still having leaking issues, although i dont know why, plumbers have had connetions for many years that are leak proof so why cant the computer industry take a lesson from them.

I have 2 fans top and front and bottom and one in the back .   Plus the air cooler inside.  I love it when i open up the case and its still perfectly dust free.    Have never had any problems with it from day one.  For close to 3 grand i would hope not...

I went to 2 displays and could never go back to 1, then i got another display and i could never go back to  2 lol   

im running a i7-6700k CPU 4 GHz  and if i had waited just alittle bit i could have gotten the next model up for the same price.. oh well.   Stupid stipping company when i got all the parts the thing i was worried about most was the CPU, i was just hoping i did not get a bad one.    And when i opened the box there it was, it had come out of its own box from the people bounding it around and was just laying there on top of the other parts...   I was so ticked off....    But everything looked fine visually and i got lucky, it has run perfectly.   

Im running a MSI gaming mobo, i had heard good things about MSI back then, and it has worked well.  But as with anything else its all mass produced by people that are mindless thinking of other things while on a assembly line.  Its ok but its nothing special.  And im running a NVIDIA GPU 

I must say i am impressed, some people focus on a few aspects of computing, but you seem to be into everything, thats awesome...