Bad Mood : Falcon030 'Doom'

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu Jan 23, 2014 5:36 pm

Secret walls are now drawn properly. In bmalph01/02 they are invisible and you can see into the corridor beyond - which is wrong.

Now they are 'hidden' as intended (spot the disjoint wallpapering job).

secwal.png


The renderer didn't understand how to handle fake walls which are not also transparent (with a transparent texture format) so it just skipped them. This affects mainly secrets but also a couple of places involving progress through the map.

If problems turn up in bmalph02 which need fixed, there will be a bmalph03 and this fix will be included. Otherwise it will be carried to beta. It doesn't interfere much with the game IMO since its only used in a few places and seeing through a wall doesn't necessarily help you get up there :).
You do not have the required permissions to view the files attached to this post.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Jan 24, 2014 9:19 am

I'm interested to know about success rates on VGA monitors. It works for me, but I have only two VGA monitors, and one Falcon->VGA adapter. This isn't exactly broad testing. So if anyone has trouble on VGA (especially:- black screen / no signal / RGB signal instead of VGA) I'd like to know about it, and the type of monitor and setup.

Also, if v0.2 works for you on VGA, but v0.1 does not, I'd definitely like to know about that too.

Thanks!

mikro
Hardware Guru
Hardware Guru
Posts: 2035
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby mikro » Fri Jan 24, 2014 12:20 pm

Hey Doug,

tried the 0.2 version today, I'm speechless. Things observed:

- when a level is finished, there's this statistics about kills etc -- it seems that double buffering is not used there, I can see "Time:" blinking from time to time
- loading times: to me it's really confusing to know when exactly has loading started/finished, or better said, when I'm supposed to press space and when I'm supposed to wait. and for the first game, it always takes quite long, maybe something as a loading icon (similar to what Quake has) would be useful
- when choosing Quit Game, pressing Y, nothing happens and after a while I got random pixels and black screen, i.e. Videl restoration doesn't work properly (RGB) -- what exactly do you do there? Videl store/restore routs are quite well known and tested, no need for experiments ;)
- doesn't work on CT60, what is no surprise since the app plays with CACR & friends

Well, that's it, once again, great work!

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Jan 24, 2014 12:43 pm

mikro wrote:Hey Doug,
tried the 0.2 version today, I'm speechless. Things observed:

- when a level is finished, there's this statistics about kills etc -- it seems that double buffering is not used there, I can see "Time:" blinking from time to time


Yes I'm not exactly sure what's going on there. I need to look at it more closely. It is true that the intermission and some other screens are quite 'quick and dirty', and some did write directly to the frontbuffer. It seems everything was set up such that the 'frontbuffer' wasn't a physical frontbuffer, and was blitted or otherwise made available to GFX hardware later, hiding a plethora of flickery effects.

In this case, it should now be DB'd - and viewing the opposite buffer shows a huge amount of flicker as expected. So whatever is happening, I guess is happening to both buffers at once...

mikro wrote:- loading times: to me it's really confusing to know when exactly has loading started/finished, or better said, when I'm supposed to press space and when I'm supposed to wait. and for the first game, it always takes quite long, maybe something as a loading icon (similar to what Quake has) would be useful


I agree! There's actually a floppy icon or something similar in the IWAD file and I was planning to use it (also a tortoise/snail for low FPS I think, from memory?) however I'm not sure yet if the game is already trying to draw it to the wrong buffer or its just been left out. I'll make sure it goes in the tracker.

As mentioned in the README/RELNOTES, the strange loading delays should go away when I add the convert switch to build the disk cache all in one go, instead of incrementally as new levels/graphics are encountered during play. So this will reduce the need for loading indicator a bit - still would be nice to have though.

mikro wrote:- when choosing Quit Game, pressing Y, nothing happens and after a while I got random pixels and black screen, i.e. Videl restoration doesn't work properly (RGB) -- what exactly do you do there? Videl store/restore routs are quite well known and tested, no need for experiments ;)


Yes the quit option doesn't work *at all*. It has nothing to do with Videl - but the game shutdown sequence and closing parts of BM from the game. Something in the restore sequence is just badly broken and has been since the start - I just haven't given it any time. One of those things in my personal notes which hasn't made it to the tracker...

mikro wrote:- doesn't work on CT60, what is no surprise since the app plays with CACR & friends


Yes, true.

It might be worth a shot doing a 'clean' build with the cache/mmu code and DSP handshake optimizations disabled. Most of them are just build switches, although some won't be (like DSP texturing - no handshake per pixel). I think it should work in principle - it just may not perform that well on a CT60 relative to its power.

mikro wrote:Well, that's it, once again, great work!


Thanks for the feedback :) When I have a 'clean' version of the program I'll ping you and we can find out if its going to work, or at least how far it gets before it dies.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Jan 24, 2014 1:19 pm

mikro wrote:- doesn't work on CT60, what is no surprise since the app plays with CACR & friends


A quick tests shows that Hatari natfeats detection on startup is causing a long row of bombs on 040/060, probably because it uses an exception handler. Is that what you saw?

I'll just take it out of the 'cpu clean' build config, since it doesn't add any value for CT60 etc. support. It will remain enabled only for the base 030 target.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Jan 24, 2014 1:37 pm

Here's a 68060 version which is mostly cpu-clean. It works in Hatari 040/060 mode @ 32MHz (but will not work on 030 due to a necessary cpusha opcode - the only place CPU state is still touched)

I still don't think it will work properly on a CT60 because there are still some handshake points which are missing. But I'd like to know how far it gets.

e.g. gets past startup / gets through menus / one frame of the game / several frames or moving around before locking up

Let me know if you get a chance to try it.
You do not have the required permissions to view the files attached to this post.

mikro
Hardware Guru
Hardware Guru
Posts: 2035
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby mikro » Fri Jan 24, 2014 2:12 pm

dml wrote:I still don't think it will work properly on a CT60 because there are still some handshake points which are missing. But I'd like to know how far it gets.

It gets as far as the game, i.e. it works wonderfully ;-) FPS 10-12 in high details and full window (with status bar)

EDIT: ok, got into the 3rd level and bam, freeze. But everything is sooo fast, esp. loading times ;)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Jan 24, 2014 2:24 pm

mikro wrote:
dml wrote:I still don't think it will work properly on a CT60 because there are still some handshake points which are missing. But I'd like to know how far it gets.

It gets as far as the game, i.e. it works wonderfully ;-) FPS 10-12 in high details and full window (with status bar)

EDIT: ok, got into the 3rd level and bam, freeze. But everything is sooo fast, esp. loading times ;)


Ok not too bad then :-)

I think it shouldn't be hard to track down the sketchy DSP handshakes and insert them. I just got bored at some point and stopped, if it seemed to work on 030, and didn't look like an edge case.

Does the sound work? I'd expect it to be a bit wrong since a DMA buffer is written and may be cached. Perhaps too much time passes between writing and DMA occuring so the problem is obscured.

Would be interesting to raise the FPS cap back to 35 (PC compatible), to see what happens. The 68060 will eat the game code easily.

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 870
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby EvilFranky » Fri Jan 24, 2014 2:25 pm

Looks the an opportunity for a separate fork?

Sent from my Nexus 4 using Tapatalk

mikro
Hardware Guru
Hardware Guru
Posts: 2035
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby mikro » Fri Jan 24, 2014 2:26 pm

Yes, as far as I can tell sound works well. Feel free to send/post any updates :)


Sent from my iPad using Tapatalk

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Jan 24, 2014 2:29 pm

mikro wrote:Yes, as far as I can tell sound works well. Feel free to send/post any updates :)


Ok but TBH I just changed about 10 lines of code, and mainly 'ifd's :-D

User avatar
viking272
Captain Atari
Captain Atari
Posts: 408
Joined: Mon Oct 13, 2008 12:50 pm
Location: west of London, UK

Re: Bad Mood : Falcon030 'Doom'

Postby viking272 » Fri Jan 24, 2014 3:56 pm

mikro wrote:
dml wrote:I still don't think it will work properly on a CT60 because there are still some handshake points which are missing. But I'd like to know how far it gets.

It gets as far as the game, i.e. it works wonderfully ;-) FPS 10-12 in high details and full window (with status bar)

EDIT: ok, got into the 3rd level and bam, freeze. But everything is sooo fast, esp. loading times ;)


Is this version still locked to 12 tics, so will max at 12 FPS anyway?

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Jan 24, 2014 4:09 pm

viking272 wrote:Is this version still locked to 12 tics, so will max at 12 FPS anyway?


Yes, it idles beyond 12FPS because that's the frequency of the AI and nothing can move at intervals between those events (not even turning the player's head). So rendering extra frames between AI ticks is pointless.

To get a higher FPS the AI needs recalibrated to a new rate. The original used 35Hz.

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2310
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby calimero » Fri Jan 24, 2014 6:29 pm

Doug - it is awesome!

I finally try it, on real Falcon.

In hires mode (320x200) it looks gorgeous! I love it!

hypothetical, If someone would like to make new WADs especial for BadMood, what is biggest speed drawback (sprites, open space, distant viewpoint, lot of different textures on screen...)? or: How to make optimised wad level for BadMood? I am sure it is possible to make awesome game in hi-res with BadMood.

it really looks astonishing in hi-res, to bad that Falcon does not have few more MHz to push hi-res in descent framerate...

anyway, Doom is really playable on 16MHz with default windows size and resolution!


btw
I tried 060 version and it freeze after few minutes of gameplay (I have a filling it is related to keyboard input: to many keys = freeze (but it is only a hunch))

btw 2
@viking272 nice desktop picture @ http://devilsdoorbell.com :)
could you add 060 version to site?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
viking272
Captain Atari
Captain Atari
Posts: 408
Joined: Mon Oct 13, 2008 12:50 pm
Location: west of London, UK

Re: Bad Mood : Falcon030 'Doom'

Postby viking272 » Fri Jan 24, 2014 6:44 pm

calimero wrote:Doug - it is awesome!

I finally try it, on real Falcon.

In hires mode (320x200) it looks gorgeous! I love it!

hypothetical, If someone would like to make new WADs especial for BadMood, what is biggest speed drawback (sprites, open space, distant viewpoint, lot of different textures on screen...)? or: How to make optimised wad level for BadMood? I am sure it is possible to make awesome game in hi-res with BadMood.

it really looks astonishing in hi-res, to bad that Falcon does not have few more MHz to push hi-res in descent framerate...

anyway, Doom is really playable on 16MHz with default windows size and resolution!


btw
I tried 060 version and it freeze after few minutes of gameplay (I have a filling it is related to keyboard input: to many keys = freeze (but it is only a hunch))

btw 2
@viking272 nice desktop picture @ http://devilsdoorbell.com :)
could you add 060 version to site?

Doug mentioned WAD design a few pages back in this thread.
I think the plan is to put a FAQ together in this respect, hopefully next month.

That graphic is cool. It wasn't done by me, but submitted by a talented gfx man in the scene. You may know him as dml. :-)
I'll also host the 060 tester, of course. I wonder if I can update the page from my mobile in this M4 traffic jam!

Sent from my GT-I9300 using Tapatalk 4

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2310
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby calimero » Fri Jan 24, 2014 7:05 pm

now I need to dig out my old 386 and to make comparison ;)

is there something like -timedemo in Doom ??
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Jan 24, 2014 7:07 pm

calimero wrote:Doug - it is awesome!
I finally try it, on real Falcon.


Great! Glad you got to see it on hardware.

calimero wrote:In hires mode (320x200) it looks gorgeous! I love it!


Probably need a bigger CPU for that mode but it makes for nice screenshots :-) Sounds like 68060 can handle it reasonably well though without optimizing it.

calimero wrote:hypothetical, If someone would like to make new WADs especial for BadMood, what is biggest speed drawback (sprites, open space, distant viewpoint, lot of different textures on screen...)? or: How to make optimised wad level for BadMood? I am sure it is possible to make awesome game in hi-res with BadMood.


As viking272 mentions above, I'm hoping to have a FAQ for level design and engine/feature control through the map etc. There will need to be some guidelines because some things do affect performance in BM, more than others.

Some of the simplest observations are easy to summarize:

1) Limit the number of 'normal' visplane (floor, ceiling) textures in view at any time. Doesn't matter how many pixels are drawn - the texture count hurts because the whole texture needs posted to the DSP. Even 1 pixel showing of a new floor surface will transmit the whole texture and associated depth cue tables. It starts to impact performance beyond 6 or so. (liquid textures are unaffected by this limit - they are not transmitted to the DSP).

2) Transparent textures cost more than normal wall textures, per column and per pixel drawn.

3) Fake 'middle' walls don't hide rooms behind them even if the texture is solid, whereas a closed door does hide content beyond it.

4) 'steps' between sectors - both floor and ceiling - carry a reasonable cost because they generate short walls, and a change in floor/ceiling state, as well as polygon edges etc. Use them with care. The worst performing levels I have tested use lots of steps/height changes - sometimes with the whole level in view at once. Open-plan 'outdoor' maps with lots of height changes are expensive and need a lot of care.

5) Maps are best designed to minimize BSP complexity. That means: avoid funny angled walls. Stick to axis-aligned or true diagonals where possible. You can use any angle you like but each line may 'split' other parts of the map and cause fragmentation. It happens more often and splitting is more buggy with funny angles (see e1m1, on left side of zigzag room as you enter it - sometimes you'll see a column of slime appear vertically on the screen - this is a BSP map splitting artifact).

Wall texture count doesn't matter much. Use as many as you like, within reason :-)

calimero wrote:it really looks astonishing in hi-res, to bad that Falcon does not have few more MHz to push hi-res in descent framerate...


The main problem is bus bandwidth to the screen in truecolour mode. Things get much better with low detail and/or reduced window. The fullscreen VGA mode hack also helps by halving video bus activity.

The DSP isn't particularly loaded on a stock Falcon. It is pretty busy but still it has to wait for the CPU and bus a lot. It will be sweating buckets though with 060 driving :-)

calimero wrote:anyway, Doom is really playable on 16MHz with default windows size and resolution!


Great!

There is actually quite a high background cost for sector lighting and depth-cue/diminished lighting. It increases the cost of texture mapping by about 50%. Dropping the lighting effects make it possible to have a higher res - but it's a high price, and especially given availability of truecolour which uses it well.

A middle ground could be found with only sector lighting, by using a surface lighting cache. But this would remove the possibility of running on 4MB, which I'm still looking at. And again would look worse than the current version.


calimero wrote:I tried 060 version and it freeze after few minutes of gameplay (I have a filling it is related to keyboard input: to many keys = freeze (but it is only a hunch))


Ok thanks I'll keep that in mind.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Jan 24, 2014 7:10 pm

calimero wrote:is there something like -timedemo in Doom ??


Yes, although two important points here:

1) Only demos recorded on the Falcon will be compatible with BM. PC-recorded demos will not work (at least, if they do work they will run in very very slow motion, and objects will move incorrectly).

2) I haven't tested demo recording on the Falcon. :-)

At some point I'll look at this for beta. For now I don't know what will happen if you try it.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Jan 24, 2014 7:35 pm

viking272 wrote:That graphic is cool. It wasn't done by me, but submitted by a talented gfx man in the scene. You may know him as dml. :-)


Actually the 'nice' part is an existent Doom texture - I just worked it into a Falcon desktop.

'real' graphics talent is contributing now but I'm still going to need music and level/texture/sprite work etc... ;-)

kristjanga
Captain Atari
Captain Atari
Posts: 400
Joined: Sat Jul 25, 2009 3:35 pm

Re: Bad Mood : Falcon030 'Doom'

Postby kristjanga » Sat Jan 25, 2014 12:32 am

both versions work flawless on a Dell D1028LR crt vga monitor, I have several monitors and I will test all of them to see if any of them has problems

but what a feeling to finally see Doom on a real Atari Falcon 030 :) man I thought this day would never come, well some atari coders over at one dedicated atari irc channel did tell me that this would be impossible..

Nothing Is Impossible...
...if you believe in your self!!
Great job there Doug

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2310
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby calimero » Sat Jan 25, 2014 9:22 am

There are few videos on youtube showing Doom on 386.

Eg on 386sx 16MHz:

http://m.youtube.com/watch?v=qFG6dqQZzbU

It looks like slideshow in hires. Even on 40MHz dx it is quite slow.

But on 486 doom runs much, much smooter!
Even on 486sx 25MHz!

http://m.youtube.com/watch?v=f79a2MOBd_k

Why it runs so much better on 486? As far as I know (except double MHz) 486 is optimized 386, there is no additional instructions, but they double instruction executions adding cache and pipeline. So 25MHz 486 should fast as 50MHz 386 but in case of Doom, it looks that 486 is more than double fast ?!
Does PC Doom use FPU?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 870
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby EvilFranky » Sat Jan 25, 2014 9:24 am

Separate video RAM. I think Doug has mentioned the biggest issue regarding frame rate on the Falcon is due to the videl having to share system RAM with everything else. It's a huge bottleneck.

Sent from my Nexus 4 using Tapatalk

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Jan 25, 2014 9:31 am

calimero wrote:Why it runs so much better on 486? As far as I know (except double MHz) 486 is optimized 386, there is no additional instructions, but they double instruction executions adding cache and pipeline. So 25MHz 486 should fast as 50MHz 386 but in case of Doom, it looks that 486 is more than double fast ?!
Does PC Doom use FPU?


The 486 is a much faster CPU and has a decent sized instruction cache. That makes a massive difference.

Compare a 68040 with 68030 for similar scenario :-) My old Afterburner was about 15x faster than a typical Falcon at 2x the clock rate!

[EDIT]

Yes nonlocal video ram and usually a L2 cache between system ram and the CPU also made a difference. My early 486 had a L2 cache, whereas the 386 did not.

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 870
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby EvilFranky » Sat Jan 25, 2014 9:36 am

Saying that, the 486sx video you posted seems excessively fast...

I installed Doom on my Granda's old 486sx 25Mhz a LONG time ago, and I don't remember it being as smooth as that video.

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 813
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Bad Mood : Falcon030 'Doom'

Postby mfro » Sat Jan 25, 2014 9:40 am

calimero wrote:There are few videos on youtube showing Doom on 386.

Eg on 386sx 16MHz:

http://m.youtube.com/watch?v=qFG6dqQZzbU

It looks like slideshow in hires. Even on 40MHz dx it is quite slow.

But on 486 doom runs much, much smooter!
Even on 486sx 25MHz!

http://m.youtube.com/watch?v=f79a2MOBd_k

Why it runs so much better on 486? As far as I know (except double MHz) 486 is optimized 386, there is no additional instructions, but they double instruction executions adding cache and pipeline. So 25MHz 486 should fast as 50MHz 386 but in case of Doom, it looks that 486 is more than double fast ?!
Does PC Doom use FPU?


Intels naming was always biased by marketing with few interest naming processors in a way customers would be able to identify what they really are.

A 386SX is a stripped down 386DX. A 486SX is a stripped down 486DX. That's basically all that can be detected from names.

The 386SX is (contrary to its DX brother) in fact a 16 bit processor regarding data bus width. A 486SX is basically the same thing than its DX counterpart (a true 32 bit microprocessor) lacking its floating point unit.

If you want to compare 386 to 486, you should keep that in mind. Forget about the 386SX which was heavily crippled even according to standards of that time.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 4 guests