OldComp.cz

Komunitní diskuzní fórum pro fanoušky historických počítačů


Právě je 28.03.2024, 10:22

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 315 ]  Přejít na stránku Předchozí  1 ... 7, 8, 9, 10, 11, 12, 13 ... 21  Další
Autor Zpráva
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 10.10.2021, 17:27 
Offline
Óm Nejvyšší
Uživatelský avatar

Registrován: 07.07.2019, 22:14
Příspěvky: 3766
Has thanked: 269 times
Been thanked: 452 times
Board incompatibility is the pain in the ass with 486DLC. I changed for testing purposes FPU from average performing IIT3C87 to Cyrix FasMath 87DLC (fastest FPU for 386 as far as I know) and it's title was well deserved - it kicked up FPS in Quake 1 from 1.6 to 1.9 FPS even with 386DX. So if you have anything else try to get FPU Cyrix FasMath 87DLC, it gives you 18% performance for free, with working 486DLC probably even more.

Edit: Even with updated last BIOS second CPU doesn't start. Board should support it as there is both internal cache and external cache Enabled option in BIOS and manual is noting 486DLC as supported CPU. Something else might be broken besides that small burnt choke I replaced, but I don't know what is taking part during switching between soldered 386 and CPU in socket so I have to use working 386DX and I don't want to lose this board - nothing even possibly dangerous is allowed.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 11.10.2021, 09:07 
Offline
Kecka
Uživatelský avatar

Registrován: 29.08.2021, 13:10
Příspěvky: 59
Bydliště: telegramm: @Yftul
Has thanked: 8 times
Been thanked: 6 times
I tried another of my FPU(collective photo with a several of my fpus below):

Obrázek

Completion result now is 2.2 FPS and 436 sec.
phpBB [video]


Upd: Chris's Bench score 16.8, with 10.1 fps:
ObrázekObrázek


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 11.10.2021, 11:10 
Offline
Óm Nejvyšší
Uživatelský avatar

Registrován: 07.07.2019, 22:14
Příspěvky: 3766
Has thanked: 269 times
Been thanked: 452 times
:like: What a big difference can such a small FPU do ;). Quake running with 2.2 FPS for this level of computing is almost fluent :mrgreen:. Pity that Weitek FPU is so specific piece of hardware without broad software support, I saw testing program with mathematics for Weitek and 387 and Weitek is way faster than any 387 FPU. Even 486DX up to 66 MHz is slower.

I finally found working jumper combinations for cache on my second board (32, 64 and 128 kB), which is accepting 486DLC. But with cache enabled the board is still extremely unstable. DOS isn't running past HIMEM is testing and PC freezes with no exception... Maybe because 486DLC issues, maybe because I am lacking 16kx4bit SRAM TAG for Write back (486DLC is able to run in write back), maybe setting of cache is not yet pefrect, who knows. I will investigate it further.

I am assessing obtaining newer revision of 486DLC-E if all other options fail, who knows why it is not behaving in proper way. Cyrix is "famous" with this behaviour. One CPU revision was working, but another was not... I will get setup program cyrix.exe to test it more.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 11.10.2021, 11:41 
Offline
Kecka
Uživatelský avatar

Registrován: 29.08.2021, 13:10
Příspěvky: 59
Bydliště: telegramm: @Yftul
Has thanked: 8 times
Been thanked: 6 times
Actually, I also ordered on ebay 486DLC/E. It will be interesting to compare results.

Regarding cyrix.exe, I already have cyrix.zip archive(https://www.vogons.org/viewtopic.php?f=46&t=34488&start=20) and can share it if you will send me your email in a private message.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 11.10.2021, 12:32 
Offline
Óm Nejvyšší
Uživatelský avatar

Registrován: 07.07.2019, 22:14
Příspěvky: 3766
Has thanked: 269 times
Been thanked: 452 times
Results should be completely the same. There are no internal changes in accordance with processing power. L1 cache is still 1 kB only, no changes for core. What could differ is that this CPU is mentioned namely in my second board manual. 486DLC for unknown reason doesn't work with it (older revision I have). Ti486DLC-E is stated as supported so maybe all my problems will be solved with just newer CPU revision. Second board has 2x bigger cache, quite faster RAM access and overall is working very well. 1,9 FPS in Quake with just 386DX is quite good result. With 486DLC-E 1kB L1 + 256 kB L2 cache it must be only better. 256 kB cache is more typical for 486 class of board than 386.

Thanks for cyrix.exe, I found another link on vogons with probably working utility along with 586 and 6x86/MII utilities for enabling hidden/sometimes tricky behaving or on some chipsets unsupported registers/functions. First I must try more settings in BIOS, as I understood from vogons thread you must have some 4G memory area non-cacheabe to get L1 cache working. There is only L1 cache and 0 kB from 4GB or L1 cache as part of not completely 4GB cached memory. This feature is disabled as I remember so today I will enable it and test it, maybe it is the last obstacle before working cache and 486DLC. That Ti486DLC-E I need for second board, which doesn't accept 486DLC at all.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 11.10.2021, 22:36 
Offline
Óm Nejvyšší
Uživatelský avatar

Registrován: 07.07.2019, 22:14
Příspěvky: 3766
Has thanked: 269 times
Been thanked: 452 times
So after a day of hard work, in the end showing the computer lit blow torch and pliers, I was able to force shitty M320 board to accept L2 cache and run. Mere 32 kB so far, but even this was enough to sky-rocket the provided computational power against cacheless scenario. 2,1 FPS in Quake 1 with 32 kB cache is much better than 1,6 FPS with 386DX with 256kB L2 :-).

I also used original Cyrix software installation disk for 486DLC/SXL CPUs, which is able to automatically enable L1 and L2 cache working together in harmony, preventing cache coherency problems and do it every boot through autoconfig.bat. Based on information I got today about DMA queries to L1/L2 cache, causing without proper software setup system breakdowns I strongly recommend to use this disk and install utility to avoid this problems. It is working very nicely... Difference with cache enabled is 15 000 points vs. 4250 points in NSSI for CPU, with 128 kB it will be even better, especially games.

It has catch however - you need Cyrix FPU (or Intel, which is much slower). IIT and other obscure FPUs won't pass tests and program will refuse to install so kick it out anyway :-). Also it seems to me there is hardwired path for installation from A:\ for the install program. It is not possible to install from C: or D:, only from floppy. But this is probably small, loughable obstacle for people, who solder their own 386 board by hand anyway :-).

I used 7zip for compression, it creates smaller archives. Cyrix3 contains files extracted from .img, second image is full FDD image. It is enough to simple copy all files to empty floppy.


Přílohy:
cyrix_486slc2_install.7z [292.12 KiB]
110 krát
Cyrix3.7z [263.25 KiB]
113 krát
Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 12.10.2021, 07:21 
Offline
Óm Nejvyšší
Uživatelský avatar

Registrován: 07.07.2019, 22:14
Příspěvky: 3766
Has thanked: 269 times
Been thanked: 452 times
About that cache - cache bigger than 32 kB leads allways to data corruption on address 0108080h, that is 32 kB and 128 B above 1 MB - 1081472 B. No matter what cache I use this prevent XMS to be loaded. I suspect two things. First board and chipset, pc chips is famous for cheap selling semi-working chips of other manufacturers, which failed to pass quality inspection. 32 kB is working so put it on and sell it fast. Second option is shitty, worn off socket for cache. I assess replacement with precise ones but my personal bet is pc chips chipset. We shall see... I also will get 16k x 4 SRAM for write back capability.


Naposledy upravil Czech Human dne 12.10.2021, 07:49, celkově upraveno 1

Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 12.10.2021, 07:36 
Offline
Kecka
Uživatelský avatar

Registrován: 29.08.2021, 13:10
Příspěvky: 59
Bydliště: telegramm: @Yftul
Has thanked: 8 times
Been thanked: 6 times
Czech Human píše:
About that cache - cache bigger than 32 kB leads allways to data corruption on address 0108080h, that is 32 kB and 128 B above 1 MB - 1081472 B.


Did you used high memory dos feature? If so, looks this issue related with #A20 line behavior changing.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 12.10.2021, 08:18 
Offline
Óm Nejvyšší
Uživatelský avatar

Registrován: 07.07.2019, 22:14
Příspěvky: 3766
Has thanked: 269 times
Been thanked: 452 times
I normally have DOS HIGH option and XMS. Total amount of RAM is 32MB, so my problem with only 32 kB of cache is, there is only first 8 MB cached (and 8 MB is not too much for games I would like to test, Quake for sure will benefit from more RAM than bare limit).

As I tested yesterday, cache is 33 us, above 32 kB it is 83 us until 8 MB. Over 8 MB until the end of RAM it is "standard" non-cached 54 us. So I have strong motivation to enable all 128 kB - only then the whole 32 MB of RAM will be cached and 4x bigger cache = more FPS.

The tricky thing is if I set only 32 kB of cache, everything is ok. If I completely disable cache, everything is ok. But any increase to 64/128 kB no matter what cache chips I use (I have 4 sets of chips from 15 to 25 ns) end allways with "unreliable memory" problem or PC even crash during boot because of data corruption. If I continue with DOS LOW option I can run some small test programs (but NSSI fails to start, probably by touching hardware too much). Having virtually 640 kB of RAM is not very usable though. So there is something fishy on the board but I don't know what. I have big lack of knowledge in this area, I will find out more about A20 line. And of course all XMS memory testing is done before cyrix software or even drive C: kicks in so this should be out of the game.

My concern is that chipset is shitty and 32 kB cache will only work. It is still much faster than 386 but I think more cache would help overall performance further. It is only a bit slower than 486DX 33 MHz now, you can play DOOM reasonably fast, but it is not showing full potential yet :-).

Edit: Based on access time, you can assess what type of access to cache you have - serial or parallel. Serial (for 99% my shitty board) is slower because first it asks cache and if there is miss, then and only after it asks RAM. Access time is adding 33 us +55 us = approx. 83 us. Which is actually slower than just uncached RAM. Parallel access asks RAM and cache together and if cache hit, RAM query is cancelled. If cache miss, RAM query is completed. Approx. time would then be 33 and 55 us, which is faster. This brings back the question what is better - small cache and quasi parallel access to the 75% of RAM, or bigger cache and slower access to the whole RAM....


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 12.10.2021, 11:26 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 14.05.2013, 19:10
Příspěvky: 1486
Bydliště: Kurim
Has thanked: 828 times
Been thanked: 577 times
So I built myself Sound Barker, works on first run, sound is OK on all tests. I played Monkey Island shortly, then one level of DOOM and after return to DOS, my CF card in XT CF Lite (with XT IDE Universal BIOS) is corrupted quite badly :-( Need to say that DOOM sometimes stopped for about 10 seconds while autosaving (blue disk icon in right bottom corner). It is either some XT CF Lite or CF incompatibility, or the Sound Blaster is really somehow corrupting disk transfers. I will try with IDE flash DOM module using standard BIOS later.


Přílohy:
Groza386_disk_errors_with_SoundBarker.jpg
Groza386_disk_errors_with_SoundBarker.jpg [ 304.68 KiB | Zobrazeno 2221 krát ]

_________________
http://www.8bity.cz
Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 12.10.2021, 11:46 
Offline
Kecka
Uživatelský avatar

Registrován: 29.08.2021, 13:10
Příspěvky: 59
Bydliště: telegramm: @Yftul
Has thanked: 8 times
Been thanked: 6 times
It is very strange, I haven't any issues with my cf on Alexandru's board. I used snark in dos and windows games - all ok. One thing I has not tried yet - floppy.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 12.10.2021, 11:55 
Offline
Óm Nejvyšší
Uživatelský avatar

Registrován: 07.07.2019, 22:14
Příspěvky: 3766
Has thanked: 269 times
Been thanked: 452 times
Try to install that Cyrix CPU software first, maybe it will fix DMA transfers quality/possible data corruption. It is the main purpose of it, if cache is not set properly, you lose data.

I think it also depends on CF itself, some CF can have issues with such old drive controllers. I had similar problem with 386DX - I saw file structue even on old 256 MB CF card but was unable to copy/open files from CF to hard drive. In the end names were changed for some gibberish and some files were corrupted. Big OS was than complaining that CF needs check and repair. I am not sure if I had 100% correct cylinders/head/sectors numbers in BIOS. With Cyrix fix installed no problems with copy/modifying of data even on CF so far.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 12.10.2021, 16:35 
Offline
Site Admin
Uživatelský avatar

Registrován: 11.05.2013, 23:48
Příspěvky: 10111
Bydliště: Praha
Has thanked: 1953 times
Been thanked: 1517 times
Tohle potvrzuju. Měl jsem to u jednoho PC stejné.

_________________
Amiga/Amstrad/Atari/Commodore/Mac/Nintendo/PS/PC/Sega/Tandy/ZX


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 12.10.2021, 19:52 
Offline
Óm Nejvyšší
Uživatelský avatar

Registrován: 07.07.2019, 22:14
Příspěvky: 3766
Has thanked: 269 times
Been thanked: 452 times
Finally success! Based on highly scientifical testing of all cache-connected jumper combinations (there is no manual/jumper settings for my board on the internet) I finally was able to utilise the whole 128 kB of L2 cache with really great impact to performance. Quake is now running with 2,4 FPS but much more "fluently" if I can say in comparison with 32 kB cache/386DX, Chris Benchmark 10,4 FPS, Superscape benchmark (1) has score 20,4. PC Player Benchmark 5,7. SpeedSys CPU score is 10,2, Landmark has 167,54 MHz CPU and 157,23 MHz FPU. DOOM is now really playable with low settings 2372 realticks 32 FPS and high detail 9199 realticks - 7,8 FPS. NSSI shows 90-95% of 486DX-33 performance 15975 Dystones and 5415 Kwhetstones. Not bad for such system I think. Whole PC is now much more responsive thanks to the big L2 cache. So problem solved, all the fun is gone :-D. Now the second board with full 256 kB L2 awaits newer 486DLC-E CPU to arrive to have 2x size of the fun 8-)...

I can only wait for my 16kx4 TAG SRAM to enable Write-back cache and gain even a bit more power with this board.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: 386 SBC by Alexandru Groza
PříspěvekNapsal: 12.10.2021, 20:42 
Offline
Kecka
Uživatelský avatar

Registrován: 29.08.2021, 13:10
Příspěvky: 59
Bydliště: telegramm: @Yftul
Has thanked: 8 times
Been thanked: 6 times
I just tested floppy. Booting, copying files and checkit testing - all OK.

Obrázek Obrázek


Nahoru
 Profil  
 
Zobrazit příspěvky za předchozí:  Seřadit podle  
Odeslat nové téma Odpovědět na téma  [ Příspěvků: 315 ]  Přejít na stránku Předchozí  1 ... 7, 8, 9, 10, 11, 12, 13 ... 21  Další

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]


Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 10 návštevníků


Nemůžete zakládat nová témata v tomto fóru
Nemůžete odpovídat v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete přikládat soubory v tomto fóru

Hledat:
Přejít na:  
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz