Doom SNES Hacking Guide/Documentation

[Revenant]

I think the 8MB max figure is probably not correct either. There are two different parts of the address space that can be mapped to an additional 2MB, but it's likely that they're both just a mirror of each other, like how the lower 2MB of Super FX ROM (and most other SNES cartridge boards) work. (Martin Korth's documents say the second additional region is 4MB, but bsnes and higan both disagree with this). So the most likely/realistic actual limit is probably 4MB.

Anyway, I'm skeptical that having several extra megabytes of space available for CPU-side code will provide much benefit. The biggest restriction is that the CPU and Super FX cannot access the cartridge ROM/RAM simultaneously, so any CPU-side code that runs while the Super FX is active must be run out of system RAM, which is strictly limited to 128 kilobytes (less however much of it is used for game state). That's not accounting for the fact that the SNES CPU is, indeed, very slow.

Even given that, I don't really know how much room there is for optimizing the Super FX side code. The thing to remember about the Super FX is that it's not a GPU; it has no built-in 3D or texture mapping capabilities at all. All of that still has to be done in software running on a coprocessor, and it's still subject to all the same limitations with regard to execution time. I haven't tried doing a basic profile of the FX-side code to see how much idle time there is between renderer frames, but it's probably not a very promising amount, and trying to optimize for speed vs. space is probably more or less out of the question given the amount of the lower 2MB that's already taken up by Super FX stuff alone.

[Maes]

Even if you get by the ROM size and RAM/ROM access limitations, the main CPU is still too weak to run a "proper" port of Doom -the very least it cannot run straight Linux Doom v1.10 at playable frame rates, and probably cannot even fit a working E1M1 into RAM, unless you abolish the dual disk/RAM form of level data, and separate immutable/mutable parts of the levels, and access e.g. fixed data like the position of vertexes, linedefs etc. from ROM, while variable things like sector height are stored in RAM. That means making a lot of adaptations to the code, and "cooking" some or all of the level data, including each time you want to add a new custom level.

Even with that out of the way, you'll really need to write some clever code to take advantage of the "hardware acceleration" on the SNES, with or without the SuperFX chip. On real hardware, it would really help if you could add some extra RAM on a cart, if anything, to increase the memory bandwidth in order to support drawing higher-res graphics and floor/ceiling textures, as I suspect that SNES Doom is already pushing the total memory bandwidth of the system to the limits, which is already at a premium.

[lunaark]

Revenant said:

I think the 8MB max figure is probably not correct either. There are two different parts of the address space that can be mapped to an additional 2MB, but it's likely that they're both just a mirror of each other, like how the lower 2MB of Super FX ROM (and most other SNES cartridge boards) work. (Martin Korth's documents say the second additional region is 4MB, but bsnes and higan both disagree with this). So the most likely/realistic actual limit is probably 4MB.

Anyway, I'm skeptical that having several extra megabytes of space available for CPU-side code will provide much benefit. The biggest restriction is that the CPU and Super FX cannot access the cartridge ROM/RAM simultaneously, so any CPU-side code that runs while the Super FX is active must be run out of system RAM, which is strictly limited to 128 kilobytes (less however much of it is used for game state). That's not accounting for the fact that the SNES CPU is, indeed, very slow.

Even given that, I don't really know how much room there is for optimizing the Super FX side code. The thing to remember about the Super FX is that it's not a GPU; it has no built-in 3D or texture mapping capabilities at all. All of that still has to be done in software running on a coprocessor, and it's still subject to all the same limitations with regard to execution time. I haven't tried doing a basic profile of the FX-side code to see how much idle time there is between renderer frames, but it's probably not a very promising amount, and trying to optimize for speed vs. space is probably more or less out of the question given the amount of the lower 2MB that's already taken up by Super FX stuff alone.

I really need to learn how the SNES works.

I know this is next step after impossible, but if you were able to run doom on an SA-1 and Super FX at the same time, that would be awesome

[VGA]

GeckoYamori said:

Can you even run Super FX, or any other chip-extended ROMs on something like a flash cart? Is there some kind of software/emulation solution built into the carts for those situations?

I believe the best solution for SuperFX games requires any SuperFX game cart to be connected on top of the flash cart. Other chips are emulated or replicated or whatever. But for SuperFX you need the actual hardware ... so any SuperFX game will do.

Most flash carts just don't support SuperFX games at all.

[Revenant]

The "pass-through" solution doesn't work for the Super FX the way it does with the DSP-1, etc., because the Super FX sits between the ROM and the cartridge connector, rather than sharing the bus the way most other expansions do. (To my knowledge, this design is also the main reason why the SFX and CPU cannot access the cartridge simultaneously.)

There are also no flash carts which currently support the SFX, so your only options are to emulate the game or buy the actual cartridge, or solder a replacement EEPROM into a donor cart.

[lunaark]

Revenant said:

The "pass-through" solution doesn't work for the Super FX the way it does with the DSP-1, etc., because the Super FX sits between the ROM and the cartridge connector, rather than sharing the bus the way most other expansions do. (To my knowledge, this design is also the main reason why the SFX and CPU cannot access the cartridge simultaneously.)

There are also no flash carts which currently support the SFX, so your only options are to emulate the game or buy the actual cartridge, or solder a replacement EEPROM into a donor cart.

Well, if it causes many limitations, then why would they design it like that, because they should've known.

I also realized that's why BSNES-Plus has the Game Pak RAM Access rapidly switching from CPU to Super FX.

[Revenant]

If they had both processors sharing the bus (like the SA-1 does), then both of them trying to access the bus at the same time would still cause issues. The SA-1 is able to be stalled when the CPU is using the bus at the same time, but that makes things slower than they usually need to be, so often either one or the other will still end up running code out of RAM instead, just like you do with the Super FX.

Having the access to the cartridge be controlled like it is with the Super FX is much simpler in terms of actual hardware design. And as for the pass-through limitation, it's not like Nintendo were trying to accomodate for flash carts when they were designing the hardware.

[Scet]

The only way I can see of running this on hardware outside of ripping out an old SuperFX chip is via an FPGA board. Making a flash cart with the FPGA in place of the SuperFX. This is what most of the cheapo "100 Atari games inside a joystick" things use. I know there's code for most of the classic consoles, don't know about the SuperFX. Really this is another form of emulation though, hardware instead of software.

[VGA]

Revenant said:

The "pass-through" solution doesn't work for the Super FX the way it does with the DSP-1, etc., because the Super FX sits between the ROM and the cartridge connector, rather than sharing the bus the way most other expansions do. (To my knowledge, this design is also the main reason why the SFX and CPU cannot access the cartridge simultaneously.)

There are also no flash carts which currently support the SFX, so your only options are to emulate the game or buy the actual cartridge, or solder a replacement EEPROM into a donor cart.

It seems you are correct and the Super UFO Pro 8 flash cart is just misadvertised.

[lunaark]

Revenant said:

I think the 8MB max figure is probably not correct either. There are two different parts of the address space that can be mapped to an additional 2MB, but it's likely that they're both just a mirror of each other, like how the lower 2MB of Super FX ROM (and most other SNES cartridge boards) work. (Martin Korth's documents say the second additional region is 4MB, but bsnes and higan both disagree with this). So the most likely/realistic actual limit is probably 4MB.

Anyway, I'm skeptical that having several extra megabytes of space available for CPU-side code will provide much benefit. The biggest restriction is that the CPU and Super FX cannot access the cartridge ROM/RAM simultaneously, so any CPU-side code that runs while the Super FX is active must be run out of system RAM, which is strictly limited to 128 kilobytes (less however much of it is used for game state). That's not accounting for the fact that the SNES CPU is, indeed, very slow.

Even given that, I don't really know how much room there is for optimizing the Super FX side code. The thing to remember about the Super FX is that it's not a GPU; it has no built-in 3D or texture mapping capabilities at all. All of that still has to be done in software running on a coprocessor, and it's still subject to all the same limitations with regard to execution time. I haven't tried doing a basic profile of the FX-side code to see how much idle time there is between renderer frames, but it's probably not a very promising amount, and trying to optimize for speed vs. space is probably more or less out of the question given the amount of the lower 2MB that's already taken up by Super FX stuff alone.

So basically the system RAM is totally full (well you said not much benefit, which implies there is some room but not alot). You have to remember mostly routines will be replaced, and that space plus whatever left over space in the system RAM can be used for a routine replacement. I see what you mean though, and I will check the average kilobyte usage of system RAM in BSNES-Plus, and take note of peak usage, and will then figure out how much useful routines can be added without the system RAM overflowing in certain situations.

I don't know if what I am saying will work, but math can bring you a long way when it comes to these kinds of things.

But I do take what you are saying seriously, because you know what you are talking about (you contributed a fair amount to BSNES-Plus, and making a SNES debugger is difficult I can imagine.)

Revenant said:

If they had both processors sharing the bus (like the SA-1 does), then both of them trying to access the bus at the same time would still cause issues. The SA-1 is able to be stalled when the CPU is using the bus at the same time, but that makes things slower than they usually need to be, so often either one or the other will still end up running code out of RAM instead, just like you do with the Super FX.

Having the access to the cartridge be controlled like it is with the Super FX is much simpler in terms of actual hardware design. And as for the pass-through limitation, it's not like Nintendo were trying to accomodate for flash carts when they were designing the hardware.

So the theoretical 5 times speed increase when using a SA-1 is actually lower? (by that I mean 2.68MHz 65816 + 10.74MHz SA-1 = 13.42MHz total [slightly more than 2.68MHz X 5, which would be 13.4, but the difference is so tiny that it doesn't matter] because there is slowdown? How much slowdown?

I also just learned the CPU in the SNES has a 21MHz clockspeed, but it is reduced to 2.68MHz and 3.58MHz (I think there is also a hilariously low 1.79MHz mode), I can only imagine how much potential the SNES could have had if they used that 21MHz.

Think about it, if the SNES CPU used that 21MHz, and since the Super FX is also 21MHz, they could've made a straight Doom port (I think the recommended PC was a 33MHz 386, but here we have a 21MHz CPU with a 21MHz co-processor doing the graphics, meaning you were effectively running Doom at 42MHz, which is 9MHz more than the 386)

I had a SNES when I was a little kid (even though I am a near-mid 2000's kid) and I can only imagine playing much better games on it, because the SNES was really what I played games on.

[Maes]

Sadly, even with a 10x speed increase, the 65C816 CPU used in the SNES would yield about 15 MIPS, at best. To put this into perspective, a 486 CPU (SX or DX, doesn't matter, as long as the FPU isn't used) gives about 1 MIPS/MHz (or nearly one ipc, instruction per CPU cycle). The 65C816 is about 0.42 ips, aka only 42% of the instruction processing speed of a 486, af frequency parity, and that's without even taking memory speed and bus width differences into account (16-bit vs 32-bit). That's a very rough comparison, as one average instruction on two different CPU architectures many not be comparable in effectiveness, but in this case we can safely say that the 486 is much more efficient even in that respect.

Simply put, the SNES would not have the computrons to properly run Doom even if you jacked up the CPU speed to 100 MHz, without also vastly improving memory and storage access. However, there's a port of Doom that runs on this CPU, and with the speed jacked up to 16 MHz. As you can guess, it runs poorly. Then again, it's a "straight" port, with no acceleration or optimization, plus a lot of bottlenecks. It's possible that, a port with proper DSP acceleration, might do better.

[Revenant]

TheLoneSurvivor said:

I also just learned the CPU in the SNES has a 21MHz clockspeed, but it is reduced to 2.68MHz and 3.58MHz (I think there is also a hilariously low 1.79MHz mode), I can only imagine how much potential the SNES could have had if they used that 21MHz.

The reason the CPU's clock signal is reduced so much is because different parts of the system (and cartridge) memory had comparatively slow access time requirements (120 or 200 ns for ROM, 200 ns for RAM, and I believe the 1.79MHz clock speed is used when accessing some of the internal I/O registers). To get the full 21MHz you would have essentially needed ROM/RAM that operated 6 to 8 times faster.

And, as Maes points out, the SNES CPU at any speed is much less sophisticated than a 486 or probably even a 386.

[lunaark]

Did it really take 21 years to do this? 21 YEARS, let that sink in.

I swear to god people know the internals of every single SNES game and can make comments on every single line of code, but not this one.

Anyways, with that aside, the king of Doom SNES hacking has brought me this...

Nodes E1M1
original
Code: [Select]
Adr X Y ChenX ChenY Right BOX Left BOX RCHILD LCHILD
[00] $0000: 0B48 EF00 0000 0020 0B600B48EF00EFC0 0B480B28EF00EFC0 8001 8002
[01] $001C: 0B60 EF00 FFE8 0000 0B600B28EF00EFC0 0B600B28EE40EEE0 0000 8003
[02] $0038: 0B28 EFC0 0000 FF40 0B280A80EE40EFE0 0B600B28EE40EFC0 8000 0001
[03] $0054: 0B60 EFC0 00C0 0000 0C200B60EF00EFC0 0C200B60EFC0EFE0 8004 8005
[04] $0070: 0C20 EF00 FF40 0000 0C200B60EF00EFE0 0C200B60EE40EF00 0003 8006
[05] $008C: 0C38 EF20 0000 FFE0 0C380C20EF00EFC0 0C580C38EF00EFC0 8008 8009
[06] $00A8: 0C58 EF00 FFE0 0000 0C580C20EF00EFC0 0C580C20EE40EEE0 0005 800A
[07] $00C4: 0C58 EF00 0000 00C0 0D000C58EE40EFE0 0C580C20EE40EFC0 8007 0006
[08] $00E0: 0C20 EFE0 0000 FFE0 0C200B60EE40EFE0 0D000C20EE40EFE0 0004 0007
[09] $00FC: 0B60 EFE0 0000 FFE0 0B600A80EE40EFE0 0D000B60EE40EFE0 0002 0008
[0A] $0118: 0BB0 ED18 0000 FFF8 0BB00B60ED10ED18 0BD00BB0ED10ED18 800E 800F
[0B] $0134: 0BB0 ED10 0020 0000 0BD00B60ED00ED10 0BD00B60ED10ED18 800D 000A
[0C] $0150: 0BD0 ED10 0000 0008 0C200BD0ED00ED18 0BD00B60ED00ED18 800C 000B
--/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/--
[DD] $182C: FD80 F480 02C0 0080 0040FD80F1C0F500 0040FD80F480F500 00DC 80E0
[DE] $1848: 0040 F1C0 FD40 0080 0040FD80F1C0F500 0040FD80F1C0F240 00DD 80E1
[DF] $1864: FD80 F240 0000 0240 0040FD80F1C0F500 FD80FD00F1C0F500 00DE 80E2
[E0] $1880: 0040 F2C0 0040 0080 00800040F280F340 00800040F2C0F400 80E4 80E5
[E1] $189C: 0080 F380 FFC0 0080 00800040F380F440 00800040F280F400 80E3 00E0
[E2] $18B8: 0040 F500 0000 FF80 0040FD00F1C0F500 00800040F280F440 00DF 00E1
[E3] $18D4: 0080 F340 0000 0040 02C00080F280F440 0080FD00F1C0F500 00C1 00E2
[E4] $18F0: 02C0 F220 0000 00C0 0EE002C0ED00F800 02C0FD00F1C0F500 00A7 00E3

SNES
Code: [Select]
Address X Y ChenX ChenY Right BOX RCHILD Left BOX LCHILD
[00] $189ED4: F1C0 FF40 0B80 0040 0B800B80F1ABF1C0 8008 0B800AC0F1C0F230 8004
[01] $189EF0: F230 FF40 0B80 FFD0 0B800AC0F1ABF230 0000 0B800AC0F200F2E0 8000
[02] $189F0C: F1F8 0000 0D18 0018 0D190D18F1EFF1F8 8018 0D180D18F1F8F210 8014
[03] $189F28: F210 FFA8 0D18 FFD0 0D190D18F1EFF210 0038 0D180C20F1E0F2D6 8010
[04] $189F44: F240 FFA0 0D78 FFD0 0D780D18F210F240 8028 0D900CF0F210F298 8024
[05] $189F60: F298 FFA0 0D50 FFC0 0D900CF0F210F298 0070 0D500CF0F258F298 8020
[06] $189F7C: F298 FFC0 0D90 0000 0D900CF0F210F298 008C 0D900CAAF298F3A9 801C
[07] $189F98: F258 0028 0CF0 FFB8 0D900CAAF210F3A9 00A8 0D190C20F1E0F2D6 0054
[08] $189FB4: F1E0 FF60 0CC0 0040 0CC00BE7F1C0F220 802C 0D900C20F1E0F3A9 00C4
[09] $189FD0: F240 0028 0D90 FFCA 0E600DE0F211F2E2 8034 0DB80D78F20AF240 8030
[0A] $189FEC: F298 FFE8 0D90 FFA8 0E600D78F20AF2E2 00FC 0D900BE7F1C0F3A9 00E0
[0B] $18A008: F2E0 FF58 0C28 FF50 0C8F0B80F1D6F2E0 803C 0C280AC0F230F37C 8038
[0C] $18A024: F418 00E0 0AC0 FFE8 0C100AC0F400F49A 8044 0BA00AC0F360F418 8040
[0D] $18A040: F380 0098 0BA8 0080 0C400B47F380F400 804C 0D490BA8F308F420 8048
[0E] $18A05C: F400 00A8 0C40 0020 0CE80B7AF3DBF471 8050 0D490B47F308F420 016C
[0F] $18A078: F308 FED8 0CD0 0078 0CD00B00F2B4F3A8 8054 0D490B47F308F471 0188
--/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/-- --/--
[DD] $18B700: F3C0 0000 0140 0040 01400100F3C0F440 1810 01F00140F3C0F440 8384
[DE] $18B71C: F3C0 0040 0100 0000 01F00100F3C0F440 182C 01F00100F280F3C0 17F4
[DF] $18B738: F318 0000 01F0 0090 01F00100F280F440 1848 02C001F0F2E0F3E0 1730
[E0] $18B754: F3E0 0000 02C0 00A0 02C00100F280F440 1864 056002C0F1A0F657 1714
[E1] $18B770: F400 0000 0100 FFC0 05600100F1A0F657 1880 0100FD00F1C0F500 14AC
[E2] $18B78C: F380 0000 0560 0060 0560FD00F1A0F657 189C 0EE00560ED00F800 1030
If Left Child or Right Child > $7FFF then
to go SideBase+$37A8 (analog Subsector+Segs)

Exemple
[04] $189F44: F240 FFA0 0D78 FFD0 0D780D18F210F240 8028 0D900CF0F210F298 8024

$8028+$37a8 = $B7D0 or ($b7a8 + ($8028-$8000)/4)

Code: [Select]
$5F/3144 BD 4A 33 LDA $334A,x[$5F:334A] A:18B8 X:0000 Y:0001 P:envmxdIzc
$5F/3147 8F 82 00 70 STA $700082[$70:0082] A:37A8

Looking $18B7d0
01 F2 00 58
01 - visible SDEFS on sector


SideBase #10
Sidedefs visible: 01
Sidedefs Offset: 00F2 ($18D95E =$18D86C+ $00F2)
Sector Numb: 58

Code: [Select]
$5F/316E BD 8E 34 LDA $348E,x[$5F:348E] A:D861 X:0000 Y:0001 P:eNvmxdIzc
$5F/3171 8F 8A 00 70 STA $70008A[$70:008A] A:D86B siddefs D86B+1=D86C

If Left Child or Right Child < $8000 then
to go Nodes+$9ed4

exemple
[03] $189F28: F210 FFA8 0D18 FFD0 0D190D18F1EFF210 0038 0D180C20F1E0F2D6 8010
$189ed4+$0038= $189F0C (N line = $0038\$1C=2)

Code: [Select]
$5F/31CB BD A8 32 LDA $32A8,x[$5F:32A8] A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/31CE 8F 7C 00 70 STA $70007C[$70:007C] A:9ED4
[02] $189F0C: F1F8 0000 0D18 0018 0D190D18F1EFF1F8 8018 0D180D18F1F8F210 8014

So there is NODES. Remember, there is no REJECT and BLOCKMAP equivalents in Doom SNES, so keep that in mind while we count.

That node explanation was given to me on January 20, 2016 but I only saw it now.

What about the floor/ceiling colour index?

Quote
You are legendary bro. May you please post the sector colour index, and how to use textures on linedefs?

256 colors for the floor and ceiling.



BTW, color $FF -> F_Sky

So this brings us with NODES, and a part of SECTORS.

That was from October 18, 2015.

What about these pointers/asm code for level loading?

Code: [Select]
$5F/FAF2 22 2E 31 5F JSL $5F312E[$5F:312E] load map


$5F/312E AD D1 06 LDA $06D1 [$3F:06D1] map number
$5F/3131 48 PHA A:0000 X:2806 Y:0001 P:envmxdIZc
$5F/3132 0A ASL A A:0000 X:2806 Y:0001 P:envmxdIZc
$5F/3133 AA TAX A:0000 X:2806 Y:0001 P:envmxdIZc
$5F/3134 4B PHK A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/3135 AB PLB A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/3136 BD 82 37 LDA $3782,x[$5F:3782] A:0000 X:0000 Y:0001 P:envmxdIzc
$5F/3139 8F BF 06 00 STA $0006BF[$00:06BF] A:0402 X:0000 Y:0001 P:envmxdIzc
$5F/313D BD 14 33 LDA $3314,x[$5F:3314] A:0402 X:0000 Y:0001 P:envmxdIzc
$5F/3140 8F 80 00 70 STA $700080[$70:0080] A:18B8 X:0000 Y:0001 P:envmxdIzc
$5F/3144 BD 4A 33 LDA $334A,x[$5F:334A] A:18B8 X:0000 Y:0001 P:envmxdIzc
$5F/3147 8F 82 00 70 STA $700082[$70:0082] A:37A8 X:0000 Y:0001 P:envmxdIzc
$5F/314B BD 80 33 LDA $3380,x[$5F:3380] A:37A8 X:0000 Y:0001 P:envmxdIzc
$5F/314E 8F 84 00 70 STA $700084[$70:0084] A:7F82 vertex add
$5F/3152 BD B6 33 LDA $33B6,x[$5F:33B6] A:7F82 X:0000 Y:0001 P:envmxdIzc
$5F/3155 8F 8E 00 70 STA $70008E[$70:008E] A:01CE vertex value
$5F/3159 BD EC 33 LDA $33EC,x[$5F:33EC] A:01CE X:0000 Y:0001 P:envmxdIzc
$5F/315C 8F 86 00 70 STA $700086[$70:0086] A:C270 linedefs
$5F/3160 BD 22 34 LDA $3422,x[$5F:3422] A:C270
$5F/3163 8F 90 00 70 STA $700090[$70:0090] A:01D5 lindefs value
$5F/3167 BD 58 34 LDA $3458,x[$5F:3458] A:01D5 X:0000 Y:0001 P:envmxdIzc
$5F/316A 8F 88 00 70 STA $700088[$70:0088] A:D861 X:0000 Y:0001 P:eNvmxdIzc
$5F/316E BD 8E 34 LDA $348E,x[$5F:348E] A:D861 X:0000 Y:0001 P:eNvmxdIzc
$5F/3171 8F 8A 00 70 STA $70008A[$70:008A] A:D86B siddefs D86B+1;
$5F/3175 BD FA 34 LDA $34FA,x[$5F:34FA] A:D86B X:0000 Y:0001 P:eNvmxdIzc
$5F/3178 8F 8C 00 70 STA $70008C[$70:008C] A:F746 X:0000 Y:0001 P:eNvmxdIzc
$5F/317C BD 30 35 LDA $3530,x[$5F:3530] A:F746 X:0000 Y:0001 P:eNvmxdIzc
$5F/317F 8F 94 00 70 STA $700094[$70:0094] A:FACE Texture
$5F/3183 BD C4 34 LDA $34C4,x[$5F:34C4] A:FACE X:0000 Y:0001 P:eNvmxdIzc
$5F/3186 8F 92 00 70 STA $700092[$70:0092] A:02CE texture value
$5F/318A BD D2 35 LDA $35D2,x[$5F:35D2] A:02CE X:0000 Y:0001 P:envmxdIzc
$5F/318D 8F 9A 00 70 STA $70009A[$70:009A] A:0055 X:0000 Y:0001 P:envmxdIzc
$5F/3191 BD 08 36 LDA $3608,x[$5F:3608] A:0055 thing numb (thing)
$5F/3194 8F 9C 00 70 STA $70009C[$70:009C] A:EBC2 X:0000 Y:0001 P:eNvmxdIzc
$5F/3198 BD 3E 36 LDA $363E,x[$5F:363E] A:EBC2 things
$5F/319B 85 00 STA $00 [$00:0000] A:EEEE
$5F/319D 18 CLC A:EEEE X:0000 Y:0001 P:eNvmxdIzc
$5F/319E 69 06 00 ADC #$0006 A:EEEE X:0000 Y:0001 P:eNvmxdIzc
$5F/31A1 8F 9E 00 70 STA $70009E[$70:009E] A:EEF4 X:0000 Y:0001 P:eNvmxdIzc
$5F/31A5 BD 74 36 LDA $3674,x[$5F:3674] A:EEF4 X:0000 Y:0001 P:eNvmxdIzc
$5F/31A8 8F A0 00 70 STA $7000A0[$70:00A0] A:FE42
$5F/31AC BD AA 36 LDA $36AA,x[$5F:36AA] A:FE42 X:0000 Y:0001 P:eNvmxdIzc
$5F/31AF 8F A4 00 70 STA $7000A4[$70:00A4] A:FE83 X:0000 Y:0001 P:eNvmxdIzc
$5F/31B3 BD E0 36 LDA $36E0,x[$5F:36E0] A:FE83 X:0000 Y:0001 P:eNvmxdIzc
$5F/31B6 8F A6 00 70 STA $7000A6[$70:00A6] A:FE8E X:0000 Y:0001 P:eNvmxdIzc
$5F/31BA BD 16 37 LDA $3716,x[$5F:3716] A:FE8E X:0000 Y:0001 P:eNvmxdIzc
$5F/31BD 8F A2 00 70 STA $7000A2[$70:00A2] A:FE83 X:0000 Y:0001 P:eNvmxdIzc
$5F/31C1 BD 4C 37 LDA $374C,x[$5F:374C] A:FE83 X:0000 Y:0001 P:eNvmxdIzc
$5F/31C4 8F A8 00 70 STA $7000A8[$70:00A8] A:FE8E X:0000 Y:0001 P:eNvmxdIzc
$5F/31C8 8A TXA A:FE8E X:0000 Y:0001 P:eNvmxdIzc
$5F/31C9 0A ASL A A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/31CA AA TAX A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/31CB BD A8 32 LDA $32A8,x[$5F:32A8] A:0000 X:0000 Y:0001 P:envmxdIZc
$5F/31CE 8F 7C 00 70 STA $70007C[$70:007C] A:9ED4 nodes
$5F/31D2 BD AA 32 LDA $32AA,x[$5F:32AA] A:9ED4 X:0000 Y:0001 P:eNvmxdIzc
$5F/31D5 8F 7E 00 70 STA $70007E[$70:007E] A:0058 X:0000 Y:0001 P:envmxdIzc
$5F/31D9 BD 66 35 LDA $3566,x[$5F:3566] A:0058 Bank 2
$5F/31DC 8F 96 00 70 STA $700096[$70:0096] A:E86E sectors (end $524c - stop bytes)
$5F/31E0 BD 68 35 LDA $3568,x[$5F:3568] A:E86E X:0000 Y:0001 P:eNvmxdIzc
$5F/31E3 8F 98 00 70 STA $700098[$70:0098] A:005B Bank for adress
$5F/31E7 85 02 STA $02 [$00:0002] A:005B X:0000 Y:0001 P:envmxdIzc

thing #0 - #5 (1 - 4 spawn, 5 - teleport) = 8 byte (8 bit - settings; 8 bit - index things; 16 bit - X; 16 bit - Y; 16 bit - angle)
{Player}
things_name[$00]:='Player 1 start';
things_name[$01]:='Player 2 start';
things_name[$02]:='Player 3 start';
things_name[$03]:='Player 4 start';
things_name[$04]:='Player Deathmatch start';
{Teleport}
things_name[$05]:='Teleport Destination';

thing #6-#$3F - 6 byte (8 bit - settings; 8 bit - index things; 16 bit - X; 16 bit - Y)

============================================
Sector 10 byte settings
0 = sector_special; (sector_special shr 2)
1 = bright_room
2 = sector_bright_flash;
3-4 = sector_floor_height;
5-6 = sector_ceil_height
7 = sector_floor_color
8 = sector_ceil_color
9 = sector_tag
============================================
Lindefs 16 bytes settings
0-1 = linedefs_vertx_strt
2-3 = linedefs_vertx_end
4-5 = linedefs_type
6-7 = linedefs_angle
8-9 = linedefs_texture_offset
10 = linedefs_action
11 = linedefs_tag
========================================
SideDefs 12 byte
0-1 = sidedefs_vertx_strt
2-3 = sidedefs_vertx_end
4 = sidedefs_flags
5 = sidedefs_horizontal_scroll
6 = sidedefs_vertical_scroll
7-8 = sidedefs_texture_offset
9-10 = sidedefs_linedf_number
11 = sidedefs_sector_number

That was from October 16, 2015.

We basically have NODES, SECTORS, LINEDEFS, SIDEDEFS, THINGS, SUBSECTORS (was apart of the node explanation), SEGS (was apart of the node explanation) I found the VERTICES data too, it is really close to the PC data, with some differences (because of no transparent midtextures I think, and some other reason too.)

If you don't understand what this means, this means we have all the level data.

If you don't understand what the fact we have the level data means, it means TIME FOR SOME SNES WADS!

I can't wait to play NUTS.WAD on a SNES... (I'm crazy)

[Linguica]

Can't wait for Doom The Way Sculptured Software Did

[Job]

TheLoneSurvivor said:

If you don't understand what this means, this means we have all the level data.

If you don't understand what the fact we have the level data means, it means TIME FOR SOME SNES WADS!

Yes, that's all I needed to know. And now I'm David Copperfield, with his amazing levitating keyboard trick.

[lunaark]

petePESTILENCE said:

Custom wads!!!
(Unlikely) :D

Soon...

If you look at my thread about the Doom SNES level data, you may change that (Unlikely) :D to (I need new underwear) :0

Let's just say, get your hopes up because it is likely.

Revenant said:

The reason the CPU's clock signal is reduced so much is because different parts of the system (and cartridge) memory had comparatively slow access time requirements (120 or 200 ns for ROM, 200 ns for RAM, and I believe the 1.79MHz clock speed is used when accessing some of the internal I/O registers). To get the full 21MHz you would have essentially needed ROM/RAM that operated 6 to 8 times faster.

And, as Maes points out, the SNES CPU at any speed is much less sophisticated than a 486 or probably even a 386.

So basically the CPU is severely bottlenecked by the RAM.

[Jaxxoon R]

TheLoneSurvivor said:

bottlenecked by the RAM.

SNES in a nutshell right there.

Also, to answer that Super Mario World FX comment of yours that I missed until now, what's the point of added scripting and room-over-room to Doom?

[Quasar]

Personally I'm still skeptical of this whole thing because this "hacking" of SNES Doom has been being discussed on here for about 4 months now and in that length of time not a single utility to actually do anything to the game has come out of the process. We should at least have a level extractor by now if we really understood enough about the game to even be considering editing/adding onto it.

Unless of course certain people do have such tools and are bogarting them.

[lunaark]

Quasar said:

Personally I'm still skeptical of this whole thing because this "hacking" of SNES Doom has been being discussed on here for about 4 months now and in that length of time not a single utility to actually do anything to the game has come out of the process. We should at least have a level extractor by now if we really understood enough about the game to even be considering editing/adding onto it.

Unless of course certain people do have such tools and are bogarting them.

Only 2 damn people are working on it, me and mopoz, so what do you expect.

He was actually making a Doom SNES editor, and it looked extremely legit, even more so with all he has discovered. He says he wants it to work on real hardware, so that is a major drawback in terms of time and limitations.

[Quasar]

Most of my aggravation is related to requesting a list of offsets to the level data a few months back and never receiving a reply. I think if the level data formats are known then we should probably know where all the levels are actually stored.

With a description of the structures and such a list of offsets, I could write an extractor in C++ in 2-3 hours tops.

[MopoZ]

I did not post the program, because they are still in the "not for everyone".
Chip SFX2 address bus 2 MB. To use more - it is necessary to multiplexers. ExHi\LoRom - 8 megabytes. Many of the data are taken from the ROM, which does not allow them to dare beyond 2 megabytes. I expended SFX RAM, rewrite ASM, the data were taken from SFX RAM. CPU will move all the map data in the RAM, and SFC will have to access the RAM, not ROM.
I changed plans. It will convector PC maps. I'm working on the optimization of that map can enter the space of 64 kilobytes.

[MopoZ]

New map for snes Doom
https://youtu.be/4j1PWNX1cYI

[Job]

MopoZ said:

New map for snes Doom
https://youtu.be/4j1PWNX1cYI

http://scontent.cdninstagram.com/t51.2885-15/e35/13531821_1137023446320709_643106821_n.jpg?ig_cache_key=MTI4MjM2NDc0Nzg5OTkzMDU5NQ%3D%3D.2

Seriously, why am I the only one who's cared enough to reply?

[Doomkid]

This is awesome, I can finally port UAC Rebellion to SNES and sell it on the Russian gaming black market!

(Seriously though, this is great progress, would love to toy with this myself.)

[betabox]

Well I just now got a chance to reply and holy shit. I'm definitely keeping an eye on this for more developments.

[Quasar]

I will definitely eat all my words from earlier. Is this stuff going to be open source? I do hope so.

[MopoZ]

Once completed yet utility will be source code. and other improvements. But I wrote in Delphi, maybe ported to C ++, but it is not up to it. It remains to implement the lines of action. As it turned out, here it does not work like the original Doom, and a separate code taken out every door, platform, etc., more like a script in Hexen.

Why is there no news for a long time. I have just a job that I am not home for months. Since I work as much as possible on Doom.

[MopoZ]

https://yadi.sk/d/yhS_K_M_uZhKG

If you are interested, here is the ROM, run the emulator and watch. Maybe someone will like, is small map(not that that on YouTube). Tomorrow I leave for a business trip for a month. So after a month only continue toolkit.

[Koko Ricky]

I'm going to be a jerk and just ask outright: Is there a reason the SNES Doom aesthetic is appealing beyond nostalgia?

[MopoZ]

1) Nostalgia. I bought the cartridge 97, I've saved up money and bought it. I was 7 years old.
2) Be the first. Nobody did not hacked engine on the Super Nintendo. All the different versions have long been dismantled.