SCSI-stuff
Thanks all for your reactions on my advertisement with ZIP-drive. The lucky person who will get the ZIP I will contact him/her directly. For the unlucky: I have a second external Zip drive that I use normally on my Turbo R, but because I can't exchange between my 8250 with MK SCSI and the Novaxis/Gouda SCSI on my Turbo R, I hardly use it anymore. So, if somobody wants it realy, he/she can make me an offer for it. I have an internal SCSI-ZIP, aprox. 2 years old but in good working order, complete with 16bit PC interface board and software. (Same I use in my 8250 with MK SCSI controller) Still some fax-machines sitting here! What's wrong, I thought computers were no good when using to receive faxes! At leased it didn't work for me! When I didn't have my ISDN with second number I used one of those faxes as front end to my Telephone exchange at home, so if somebody send a fax, I would take it by phone, hear that it was a fax and then just wait, so the fax would take it over and at the same time it served me as an answering machine. When I got the second telephone line for the fax, I didn't need the luxurity of the speaker phone and answering machine on that line, so I kept this faxmachine as a normal phone on my first, normal, line and used the secand fax as a fax/telephone on the fax line. But now I took over a plain paper fax from an old vriend and I bought an ISDN telephone so both faxmachines are not necessary anymore. They are in 100% condition. So PLEASE, does anybody want to take over 1 or both faxmachines of me??? Now about SCSI: One of the persons who ask me for the ZIP drive, ask me if it was possible to get 50 pins boxed male headers for flat cable mount. Because I have connections to get them here some options: Seperate boxed flat cable connectors, male: fl. 17,50 and now the crazy thing: SCSI Extention flat cable: 2 female + 1 male conectors on a 75 cm long flatcable: fl. 15,-, so you are crazy to buy the 1st one. The female flat cable connectors are: fl. 5,- each For people who want to make a centronics connection: Centronics male and female connectors for flat cable: fl. 12,- each. But same as with the first boxed header: SCSI adapter bracket, a 50 pins centronics connector mounted on standard PC bracket with 70 cm cable with 2 female connectors: fl. 14,50 Flatcable, 50 wires, per meter: fl. 4,50 I have to buy larger quantities to get these prices, so have to collect orders before I can order the goods. Greetings and till mail! Hans-Peter Zeedijk, [EMAIL PROTECTED] MSX en anders niks! (op die P2 na dan!) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Emulators...
| That is the reason that we need new MSX. My MSX will be broken someday. |Now is the time to make new one. Then I'll be happy even though my MSX |would be broken because I can possess new MSX again. here we go with that new MSX again. The idea is very nice ofcourse, Can you tell me what the diference is between a "new" msx computer, or an emulator. Okay.. I don't have a moonsound on my emulator, but on my real MSX (which I also have) I don't have one either. | You are right. Almost all MSX emulator users had MSXs. When they met |the emulator, they was very happy because they could use great MSX softwares. |And ... it's all. It's end. They just tried to run softwares once and then |never tried after. | | That situation is ok. I don't care whether they use emulators or not. |But the important point is that the number of real MSX usres decreases |due to the emulator. A lot of real MSX users putted their MSXs into somewhere |untouchable-place because they could run some MSX softwares on PC. |They do not use real MSX anymore and they do not use even the emulator now. |I don't know exactly the situation in other countries. But I'm quite sure |that many MSX users have left MSX scene due to the emulators. Also not true. If someone was developing something on his MSX he will not stop as soon as he gets an emulator ? WHy should he ? Do you think that an assembler doesn't run on an emulator ? If someone stops developing, it's not because he started to use an emulator. he would have stopped developping it anyway ! And about leaving the MSX-scene, I'll tell you something different: When I look at the e-mails I get via my site, there are a lot of people discovering the MSX again. For years they haven't used an MSX, untill they ran into an emulator. Just take a look at me. A year ago, I didn't have a MSX or an emulator. Just by accident I ran into an emulator, and since then, I also bought a real MSX. But I rahter use the emulator, because it's faster and easier. It also save a lot of deskspace ! | Well, I think you are a very GOOD MSX emulator user. I've never seen |a guy who buy softwares for MSX emulator. However, I don't consider |making such a copy-protection in my softwares. No, you haven't, but I have seen one or two discussions about people that were going to do that, and I think that's quite stupid. Becuase maybe when they are 10 years older, they still ant to play there games or see their demos, but they will not be able to, because they don't run on any emulator due to their copy-protection. And by that time, their MSX will be broken. Please keep in mind that computers don't have unlimited lives ! kind regards, Arnaud de Klerk Go visit the MSX Emulator Page (M.E.P.) http://surf.to/msxemu http://www.casema.net/~tfh ICQ:1446 MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
falcom
ablo Vasques Bravo-Villalba wrote: Coen van der Geest wrote: Speaking of Falcom: whatever happened to them? Do they still make things? You can visit the falcom site at: http://www.falcom.com Download 'njwin' for PC to view Japanese fonts under win95. If you don't sometimes some of the pictures won't display due to your browser not being able to distinguish between text and gif/jpg header. They've got montly calendars of their current games, you can download xg/gm/gs midi files of their games (ys series etc.), you can download free demos and sometimes even free games for PC. They developed software for the PC98 (japanese pc, very slow) for a while but now most of their games are released for Playstation and. Windows 95. When I was in Tokyo last winter I bought Vantage Master (strategy with sorcery) for PC and they even released the follow ups of the Ys series for Win95 (Ys Eternal). the best part is that they run fine under my dutch version of win95. Maybe someone will eventually translate those into english also like with Dragonslayer, Sd Snatcher etc. I think hunting for the kanji/kana/hiragana on PC isn't that different from MSX. Falcom has just re-released the legend of heroes series for the playstation. And I can vaguely remember that they released a sorcerian for Win95 also. There's also a new soundtrack: The very Best of Ys... In akihabara you can even get an original SD Snatcher if you are willing to pay huge prices for it. The second hand MSX stores still do very good business there! You can get alsmost all msx-1 cartridges second hand and I also bought an original Hydelide III msx-2. (Btw, has anybody got the acommpanying tape that came with the msx-1 anniversary version as an mp3?) And then there is the Sega Saturn, they released Falcom Classics II for it. And then there's COMPILE. They still make discstations allbeit for win95. They are released every two months. Untill 4 months ago they were runnable on non Japanese windows too. But with the current versions I can't get more than half of the games to work. they released Puyo Puyo for PC and Playstation and on the Playstation it's my favourite game... Konami made a game called puroyaku baseball for the Playstation which is similar to Pennant race. The also released a puroyaku baseball 95 and 98. the gameplay is much the same as on msx. They also released project overkill which got a feel and ambiance like Metal gear 1 and is 2D, but the game is isometric. And then there are Gradius Gaiden (playstationised Nemesis) and Gradius Deluxe Pack (with gradius I and II (equivalent to nemesis I and III)) and Salamander Deluxepack... I last spotted Microcabin on a Japanese psx mag called hyper playstation remix with on de demo cd a demo of a game in which you had to skateboard throug a town and do wheelies etc.. It was 3D Anyone got any more news about these companies? Btw. If anybody is interested in some recent compile discstation stuff I'll put it up on my page. You know what? I think I'll go to Japan this sunday to see what else is new. I'll ask the guys from fony to come with me ;) Gerald MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Joystick network program working
Hi! I just succesfully transmitted a few bytes across the joystick network cable. As promised, the sources are in this mail. Final bug was removed just 15 minutes ago, so don't expect optimized code ;) There is still a weak point in the protocol I used. It can cause trouble if you send one transfer quickly after another and interrupts are enabled inbetween. I'll fix it soon. But if you just want to send one byte manually (for example to check your cable) or you don't mind to keep interrupts disabled the whole time, this source works perfectly. The problem lies in the fact that not just the triggers are fixed to '1' by the BIOS interrupt routine, but also the strobe is fixed to '0'. Since the strobe is used for the ACK signal, a strobe going to '0' because of the BIOS can be mistaken for the first ACK of a new transfer. I will fix the protocol by adding an extra step that will ensure ACK is '0' at the end of a transfer. Bye, Maarten ;--- ; SENDREC1.ASM ; My first working send receive program ; for the MSX joystick network. ; ; 25-7-98 ; Maarten ter Huurne (Kryten/Mayhem) ; [EMAIL PROTECTED] PORT_1_MASK:equ % 1100 PORT_2_MASK:equ %0100 0011 STROBE_1: equ %0001 STROBE_2: equ %0010 LEFT_MASK: equ % 0100 BACK_MASK: equ % 0010 FWD_MASK: equ % 0001 DR0_MASK: equ % 0101 DR1_MASK: equ % 1010 org #C000 BIN_START: BIN_EXEC: jp init ;in: a = joystick port (0 or 1) jp send_byte ;in: c = byte jp recv_byte ;out: c = byte init: or a jr z,init_port1 ld a,PORT_2_MASK ld c,STROBE_2 jr init_port init_port1: ld a,PORT_1_MASK ld c,STROBE_1 init_port: ld (portMask),a ld a,c ld (ackMask),a di callset_neutral ei ret portMask: db 0 ackMask:db 0 set_neutral: ld a,15 out (#A0),a in a,(#A2) or % out (#A1),a ret wait_ack: ;d = previous ACK ld a,14 out (#A0),a wait_ack_loop: in a,(#A2) xor d bit 2,a jr z, wait_ack_loop in a,(#A2) ld d,a ret send_ack: ;changes e ; signal ACK ld a,15 out (#A0),a ld a,(ackMask) ld e,a in a,(#A2) xor e out (#A1),a ret send_byte: ;c = data di ; set port ld a,15 out (#A0),a ld a,(portMask) ld e,a in a,(#A2) and %1011 or e out (#A1),a ; read initial ACK status ld a,14 out (#A0),a in a,(#A2) ld d,a ld b,8 send_byte_loop: ld a,15 out (#A0),a in a,(#A2) rr c jr c,send_byte_dr1 ; signal DR0 xor DR0_MASK or e out (#A1),a jr send_byte_cont send_byte_dr1: ; signal DR1 xor DR1_MASK or e out (#A1),a send_byte_cont: ; wait for ACK callwait_ack djnzsend_byte_loop ld a,15 out (#A0),a in a,(#A2) and DR0_MASK + DR1_MASK cp DR0_MASK + DR1_MASK jr z,send_byte_end callset_neutral callwait_ack send_byte_end: ei ret recv_byte: di ld d,FWD_MASK + BACK_MASK ld b,8 recv_byte_loop: ;d = previous trigger status ld a,14 out (#A0),a recv_byte_wait: in a,(#A2) xor d and FWD_MASK + BACK_MASK jr z,recv_byte_wait rra rra rr c in a,(#A2) ld d,a callsend_ack djnzrecv_byte_loop ld a,d and FWD_MASK + BACK_MASK cp FWD_MASK + BACK_MASK jr z,recv_byte_end recv_byte_wait2: in a,(#A2) and FWD_MASK + BACK_MASK cp FWD_MASK + BACK_MASK jr nz,recv_byte_wait2 callsend_ack recv_byte_end: ei ret BIN_END: MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Patching #2F, #30 function calls identifying DOS disks
Your method is good, but I propose an alternative one: if bit 7=1, DE-HL contains sector number, and data is transferred to DTA area; I'm not sure this is such a good idea: DTA is only used by DOS, not by the diskROM. If you start using the DTA for the diskROM, you will mix up two systems that were seperated until now. You are right. I confused #4010 ROM call with #2F and #30 DOS calls. Sorry! So, I propose to extend DOS function calls 2Fh 30h (absolute disk read/write) as follows: If bit 7 of drive number (in L register) = 0: all parameters as usual If bit 7 of drive number = 1: DE = low 16 bit of sector number (was: sector number) IX = high 16 bit of sector number (was: unused) This is the best solution I think. Please, no! To read/write sectors using 32-bit sector numbers, use new function numbers. Reason: old programs, used to =32MB partitions, should not be allowed to read sectors on partitions 32MB, because they can only mess things up. But you can't create a new function call by patching #F252 hook. MSX-DOS checks for a existing funtion call number in C before calling this hook... Then I propose a solution: let's use the method I described, but let's add a new environment item, for example SECTOR_ACCESS or so. When it is OFF or don't exists, programs trying to access sectors on FAT16 drives using the old method (bit 7 of drive number=0) will just get a "disk offline" or other error. So you can choose if you want to protect your sytem against old programs. Imagine the damage IMPROVE.COM could do on a FAT16 drive! What a nightmare! Actually IMPROVE damages FAT12 disks sometimes... More useful would be a call that tells you which filesystem is used on a particular drive. Boot sector has information enough for determine if FAT12 or FAT16 is being used on a disk: - On disks formatted with MS-DOS 4 or newer, you can find string FAT12 or FAT16 in position #36. - If this fails, check the number of clusters. 4085 or fewer means FAT12 in use. 4086 or more means FAT16 in use. So no new call is needed, I think. By the way, what method should be used for determine if a disk is actually formatted with MS(X)-DOS? MSX-DOS checks some parameters in boot sector and the first bytes of FAT but I don't know exactly in which way. I propose to check the following conditions on boot and first FAT sector, if any of these fails then we can say that it is not a DOS disk: - Sector size is #200. - Cluster size is a power of 2. - Number of FATs is at least 1. - Dummy FAT entries for clusters 0 and 1 are filled with #. Any other can be added but I think it is not necessary. - Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user http://www.geocities.com/SiliconValley/Bay/9797/msx.htm [EMAIL PROTECTED]ICQ#: 18281450 "In Windows 98, 3.000 found failures of W95 have been corrected..." Translation: 3.000.000 not found failures continue without being corrected... - MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
RE: Square Wave...
Talking about new and old games, I have to say it: FF7 sucks. There is no other way to say it. I have the CD with the musics of the game, so I didn't have to play it all to listen to them... Forget it! Most like someone said, an [...] I'm wondering that everybody is speaking about FF7 having played only a little. In my opinion, Final Fantasy VII is an excellent game. It has the same argumental quality like the others FF games and it takes profit of the 3D capabilites of the PSX. If somebody has played to the others FF, then he will see that FF7 is an excellent sequel. Final Fantasy VII is the best game that can be found for PlayStation. But then, let's go to the "final" considerations. The good thing about FF5 is that you can change "job" at any time, which gives the best playability of all multi-character CRPG I have seen. I'm sorry. I have not played FF5... I think, perhaps is some version of a FF that I have played... I have played FF1 on MSX, FF2 and FF3 on SNES. In my opinion, the best of all is FF3. Probably FF7 isn't a CRPG (!!), but Dragon Slayer VI isn't CRPG and it is an excellent game. On the other hand, the CRPG feature can be a bad thing, because it can break a good argumental line. Look, for example, those european games, like the DD series, where you can create your character. Due to this, the story line can't be as good as in a game where some points are established from the beginning. And even so, MSX "SD Snatcher" has my vote as the best CRGP I have played, for you can SEE the enemy, you don't STEP randomly at a giant crystallis or ifrit (what is the chance of a character "stepping over" something at least twice as large, burning with sulfuric fire and sparking like a fire tracer? I think you got it...) Well. But this is a feature of a lot of MSX games also. Look DS6, look FF1, for example. And this puts more realism on the game. That is, imagine that you are the adventurer, you don't see all the monsters who attack you. And to testify that 3D will NOT rule the world, take "Einhander" (it is pronounced [ain handa-] and means "one handed", in Germany), also from Square. It is a shoot'em up, most like "Gradius", but completely polygonal. Due to it's Respect to this, 3D is the future, of course. But not now. When 3D reaches his "perfect" state, a 2D game can be done as a "particular" case of a 3D environment. The problem is that the actual 3D games aren't fun, they only shows how good is his 3D engine. Well, conclusions of this: * CRPG can be a bad quality, because it can break the story line. This is the diference between RPG (DD series, for example) and ADVENTURE GAME (Final Fantasy). Personally, I prefer adventure game. * What is the problem about don't see the enemies on the map? I think that it is good, and the FF7 fighting mode is the best fighting mode that I have ever seen, for the spectacularity and also for the playability. * And, respect to the music, I agree your words... it has a few good themes, it is true. ++ |Toni Burguera Burguera | ++ | E-mail :[EMAIL PROTECTED] | ++ |9D - La Novena Dimensio | | http://www.geocities.com/Area51/Dimension/9812 | ++ MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Nostalgia...
At 18:16 29/01/99 +0100, you wrote: That's true. MSX games indeed have a certain "magic". I played Dragon Slayer 6 and XAK on the SNES, but it just isn't the same. Maybe it's the music or maybe it is the graphics. But a fact is that MSX games are best on a real MSX. I have the same with MSX emulators. That's also not the same as the real thing. I don't know why. I just feel that way. Maybe that's what they call nostalgia? I agree with you that certain games will be better on an MSX than on other systems. I still get the creeps when I play Metal Gear 2 when guards see mee (I did when Metal Gear (3) Solid was announced, in fact it is the reason I bought a PSX (that and Konami MSX Antiques vol 1, 2 and 3 )). I think it has something to do with playing a game for the first time. If you play it for the second time (and on an other system), you know the storyline already and you pay attention to other things. Just like a remake of an old movie or something. I played Castlevania on the PSX (my first PSX game, because of the audio CD) and that had that "feeling" again. And later, Metal Gear Solid. It is the true sequal to MG2-Solid Snake. Have you played Metal gear 1 2 or Contra on the NES??? Terrible!!! Still a lot of people think that's the origin of those games. Recently in Brazil we MSXers had some quarrelling with one or two game magazines, when they prepared articles about Metal Gear Solid. They were saying that Snake's Revenge (something similar to Metal Gear 1 - it isn't Metal Gear, it can't be!) was the predecessor to Metal Gear Solid. However, we've some friends who are Brazilian like us and lives in Japan, and they read in MGS's manual something like that: Chronology: Metal Gear 1 - MSX 2 - 1987 Metal Gear 2: Solid Snake - MSX 2 - 1989 Metal Gear Solid - PSX - 1998 And... Snake's Revenge, from NES, ISN'T a game from MG chronology, it was an attempt from Ultra Games to do something similar to Metal Gear to the NES. Finally, the people from the magazines were sorry 4 the mistake (they don't read manuals!), but they hadn't done any correction. So, all brain-washed readers thought that Metal Gear Solid were a sequence to that s**t called Snake's Revenge. Dammit! Only MSX have that playability... ByE! _ __ | __ \ (_| ICQ UIN: 3635907 | | M. Sc. In Numerical Modelling - UFF | |__) | _ __ _ _ __ __| | ___ Niteroi - RJ - BR +-+ | _ / | |/ __// _` | '__/ _` |/ _ \ | Sola Scriptura | | | \ \ | | (__| (_| | | | (_| | (_) | | Sola Gratia | |_| \_\|_|\___\\__,_|_| \__,_|\___/ Jurczyk Pinheiro |Sola Fide| http://pagina.de/rjp - [EMAIL PROTECTED] - [EMAIL PROTECTED] | Solo Cristi | MSX freak, X-Phile, Trekker, Christian, Transformers, | Soli Deo Gloria | Anime (Yamato!), CuD, Linux, Rock, Comics, and hate M$! +-+ ---[Portuguese]- Linux? MSX? Nao perca a 1a. ExpoSALT - 30 e 31/1/99 - Escola de Engenharia, Campus Praia Vermelha, UFF - Niteroi/RJ - http://www.wb.com.br/exposalt MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
R: NEWS TILBURG 1999
What mean this ? I can't understand, use english when you write to this ML !!! Bye, Stefano -Messaggio originale- Da: Computer Gebruikers vereniging [EMAIL PROTECTED] A: [EMAIL PROTECTED] [EMAIL PROTECTED] Data: giovedì 17 dicembre 1998 23.55 Oggetto: NEWS TILBURG 1999 TILBURG 1999 is ON Betreft: Tilburg 1999 ! Sorry dat we nog niet eerder hebben gereageerd, maar hierbij de huidige status m.b.t. de beurs Tilburg 1999 ! De reden achter de "stilte" komt zeker niet door gebrek aan interesse van ons, integendeel, maar juist door het uitstellen van de beslissing in de hoop dat we nog op de oude voet door konden gaan. Het ziet er echter naar uit dat we de beurs in zijn oorspronkelijke grootte niet meer kunnen organiseren. Dit betekent echter nog niet dat Tilburg 1999 helemaal van de baan is !! Allereerst een paar dingen op een rijtje... Tot nu toe (15 december) zijn er slechts 18 kramen gereserveerd door standhouders. Als wij zelf ook 4 kramen vullen, komen we daarmee op 22 stuks... Nu is het zo dat de Bremhorsthal pas redelijk gevuld is als er 60 tot 70 kramen staan. Met dit aantal reserveringen willen en kunnen wij zeker geen gebruik maken van de Bremhorsthal. Natuurlijk komen er altijd nog aanmeldingen bij, maar het verschil tussen nu (22 kramen) en de benodigde 60 stuks is wel heel erg groot. Wij vinden het niet juist het publiek te ontvangen in een grote zaal waar de standhouders in een hoekje opgesteld staan. Dit zou zeker geen goed doen aan de MSX. Bovendien is de huur van de bremhorsthal inclusief kramen, electra, meubilair, ect, vrij hoog ( 4000 tot 5000 gulden ). Wij verwachten dat door het wegvallen van MCCM, welk blad voor ons van groot belang was om de doelgroep over de beurs te informeren, het aantal bezoekers zeker minder wordt. Het is natuurlijk altijd leuk elkaar weer te ontmoeten, maar de kans is dus groot dat het dan voor ons een erg duur onderonsje wordt. Ik wil jullie echter vragen nog een paar dagen geduld te hebben, want wij zijn in onderhandeling voor een andere ruimte ! De opzet wordt dan echter wel iets anders. WIJ WILLEN DAN EEN GROTE MSX MEETING ORGANISEREN in een wijkcentrum. De kosten zullen dan voor de deelnemers laag zijn ( 30 gulden per 3 meter tafel, inclusief 3 standhouderskaarten ) en een geringe toegangsprijs ( 2,50 ) voor de bezoekers. Voorlopig gaan we nog uit van dezelfde datum. Het is echter nog steeds van groot belang dat we op voldoende deelnemers kunnen rekenen, en dat jullie deze dag promoten en bekend maken bij alle belangstellenden ! STOP DUS MET DIE NEGATIEVE BERICHTEN EN ZORG DAT IEDEREEN NAAR TILBURG KOMT LAAT ONS WEL EVEN WETEN WIE ER MEE DOET AAN DEZE DAG Stel dus niet uit en laat snel middels een mailtje weten of jullie willen komen (ook als je al hebt ingeschreven. We moeten immers weten of je ook meedoet in deze gewijzigde opzet..) Wij zullen jullie dan zo snel mogelijk berichten op welke locatie de MSX-MEETING wordt gehouden. Stuur dus snel een reactie naar: [EMAIL PROTECTED] of stuur een fax naar : 013 - 4560668 of bel ons op 013 - 4560668 of 013 - 4681421 ( na 19.00 uur ) Wij rekenen op jullie !!! Ad Mutsaers. MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Evolution of MSX
So why not extend e.g. fMSX or RuMSX (or whatever it is called these days) with Glide (3Dfx) support, so MSX games can become really 3D? ROTFL! This this _really_ the most hilareous suggestion/idea I've heard in ages. It was just an example of course, the main thing is that hardware extensions are too expensive and we should use the existing hardware of other platforms... Besides, 3Dfx support can also be nice for demos and stuff. But if you use the hardware of other platforms, it's not MSX anymore! If you want to use inexpensive PC hardware, make a PCI-MSX bridge/interface-board... But then again, I don't want PC hardware in my MSX! Nobody wants nonstandardized shit like in the PC, where everything hangs together by a huge amount of software-drivers that only slow down and are a source for bugs. But let's not focus on the details! Where would you like to focus on then?! I have to admit, when I first heard of MSX-emulators I thought it would be cool if an MSX programming running in the emulator would be able to use the power of the PC CPU for its own good, kinda like with Gameboy. Super-Gameboy cartridges can transfer a piece of program to the CPU of the SNES and let it run in parallel. But when I think about it now, I see a few points: 1. a PC can't even fully emulate an MSX-1 correctly yet. 2. it wouldn't be MSX and would only lead to its destruction, because if there's software that'll only run on emulators (or only run WELL on emulators) there's hardly reason to keep your REAL MSX any longer... Seriously, what's the point of putting _PC_ 3D support into an MSX _emulator_? It's just as stupid as the V9990... What's stupid about the V9990?! Besides it being a little expensive, it's a great thing. I own a Gfx9000 (first series) myself and although I haven't tried programming it yet, I will soon... I'm even considering upgrading it to a Video9000, just for the fun of it!! Video digitizing/manipulation is still something a PC can't beat a NMS8280 in! (Except for the bad quality of SCREEN 8 compared to PC, but the Video9000 will fix that) You'll get programs working with this emu only Just as with the V9990... But V9990 = MSX! Just like MSX-AUDIO = MSX, MoonSound = MSX, R800 = MSX It's easier to program for PC+Glide/3Dfx directly, then... But _MSX_ programmers dont want that...! MSX programmers want to program their MSX, not some program running on a PC that can imitate some MSX functions! An emulator for a non-existing computer HAS crossed my mind, but after thinking about it a little, a good easy-to-work-with library or engine is much better than an emulator! And with a couple of macros, an intel suddenly looks a lot more like a Z80 ;) Let's end this discussion NOW, before some crazy man implements it! Greetz, Patriek [EMAIL PROTECTED] ,-. ,. ,-. TNI on the web: | '-.| ,-. \ '-' http://www.xs4all.nl/~newimage/ Member of| ,-'| | | | ,-. The New Image | '--' | | '-' | Check out "MSX Banzai!" at: since 1991`--' '-' http://www.xs4all.nl/~newimage/MSXBanzai!/ MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX cassette port
Shevek [EMAIL PROTECTED] wrote:
On my computer, I have connected the printer port, the joystick
ports and the cassette port to some easy-accessable plugs. I'm
planning on doing the cartridge slots, too. The joystick and the
printer port are easy to access, and so is the tape motor. My
question is: How do I send data to the tape output and what kind of
signal will be on it when I do so? A connected question: What kind
of signal should I give the input-line in order to get a 0 or a 1,
when reading it? I've disassembled the bios and it looks like it I
have to put H0A or H0B on i/o-port HAB to make it high or low.
But it didn't give any voltage, when measured. Does anyone know how
to do this? Thanks, shevek
The cassette connector is for connecting to a cassette recorder, and
therefore doesn't input/output digital signals, but audio signals.
For the cassette out (to the MICrophone input of a cassette
recorder), it's an audio signal with a voltage level in the order of
10's of millivolts, and only passes through signals in a limited
frequency range (some 10's up to a couple of KHz.). So no use for
controlling anything. It's coupled to register C, bit 5 of the PPI
(Programmable Peripheral Interface, a 8255 or compatible IC).
The cassette input takes an audio signal. Same limitation here:
frequency limited, and no exactly defined or fixed input levels. This
signal is input through Port A, bit 7 of the PSG (Programmable Sound
Generator).
The cassette motor connections are usually simply hooked up to a
relais (that's giving the well known clicks when giving MOTOR ON or
OFF), and it's controlled through register C, bit 4 of the PPI ('next
to' the cassette write signal), with "0" meaning "motor on".
The PSG is located starting at I/O-address A0h (-A2h), so to read the
casette input signal:
out (hA0), 14 ;set PSG register 14 (=port A)
after this, bit 7 of I/O-port hA2 contains the cassette input
signal.
For the PPI (on I/O-ports A8-ABh):
out (hAA), inp (hAA) and b1110 or:
out (hAB), b0xxx1000
("x" = don't care)
Sets cassette motor on,
out (hAA), inp (hAA) or b0001 or:
out (hAB), b0xxx1001
sets cassette motor off.
out (hAA), inp (hAA) or b0010 or:
out (hAB), b0xxx1011
sets cassette output ("MIC") to "1"
out (hAA), inp (hAA) and b1101 or:
out (hAB), b0xxx1010
sets cassette output to "0"
The 1st instructions shown above, address PPI register C on its 'own'
I/O-address, the second instructions do the same, but in a different
way, by using a single bit set/reset function of register C of the
PPI (also used in the BIOS routines).
Ofcourse, you'd have to do some assembly programming to get a decent
audio frequency tone out of the cassette port.
If you're thinking of using it to control anything, like LED's,
relais, other hardware, I would use the printer port or the joystick
port instead.
Greetings,
Alwin Henseler([EMAIL PROTECTED])
http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page)
http://www.twente.nl/~cce/index.htm (Computerclub Enschede)
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joystick network program working
Sorry, had to be in English Maar als je op msx gaat kijken wat er allemaal aan een dinplug gekoppeld kan worden (weliswaar ook verschillende, maar toch: cassette, verschillende video-uitgangen, midi-aansluitingen) On MSX there are also several DIN onnectors used: casette, video and midi Ook hier is het dus gemakkelijk om foutewn te maken. En het is net wat je zegt: Als er fouten gemaakt kunnen worden kun je er donder op zeggen dat het gebeurt. Heette die vent niet Murphy die dit bedacht? It is very easy to make mistakes. Just as you said: if errors can occur, they will occur! Wasn´t that guy called Murphy who made this up? Groetjes greetings Maico Arts MSX-NBNO -Oorspronkelijk bericht- Van: Alex Wulms [EMAIL PROTECTED] Aan: [EMAIL PROTECTED] [EMAIL PROTECTED] Datum: donderdag 30 juli 1998 23:09 Onderwerp: Re: Joystick network program working ] Jeroen Smael wrote: ] ] To me it doesn't matter which connector(s) is/are used. The tulp plugs ] suggested by Alex Wulms seem (at least to me) the best choice. Why: ] (1) they are easy to come by (three colors should be no problem as the ] standard color for CVBS is yellow and most shops also sell black ] ones). ] ] The DB9 connectors as just as easy to come by, bought some today. (Gld.3,-) I agree that they are as easy to get. Even more, if you can't get a DB9 connector, you simply can't build your network cable since you need one anyway to connect to the MSX. ] This way every MSX only needs just one cable with ] 2 female and 1 male DB9 connectors This however is very dangerous. Since there are two female connectors on the cable, which both can be plugged into the MSX, you will have the risk that people will plug the wrong one in their MSX. And believe me, if errors like this one can be made, they will be made! Please let not get us in the same kind of mess as the computer industry got into with the serial cables (null modem, DTR-CTR, DTR-DTR fully wired, etc.) or with the SCSI cables (25-pin RS232 like connectors, large 50 pin centronics, small 50 pin centronics, 50 pin ribbon with screws, 50 pin ribbon with clips, etc.)! I still think that we should have only one DB9 connector. And on the other side two connectors with support for at least 3 signals and the ground. One connector female and the other one male. I don't care that much about the type. It need not necesarily be tulip connectors as I suggested in my first memo. It can also be something different. How about DIN connectors? Are they still widely available? They used to be back in the 70's for audio equipment but there they have been superseeded by the tulip connectors. At least, in the home audio industry. I believe that the pro's still work with DIN so that should perhaps be a very viable choice instead. Kind regards, Alex Wulms -- Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever See my homepage for info on the *** XSA *** format http://www.inter.nl.net/users/A.P.Wulms MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
RE: Weak Plataform...
(...) "Jet Set Willy II" is also boring,
HERETIC!!! You'll burn in the hell, along with Bill Gate$!
Hmm, quite difficult for me. First, I'm atheist, so I cannot
go to hell. Second, Bill Gates cannot burn in hell because he
made it, I cannot believe he hasn't made some windowsless security
system against selfburning.
Hmm... a philosophical question... If you are atheist, then hell doesn't
exists? hmm... you have saved the soul of the whole world!! ;-)
Okay, okay, talking (a little more) seriously, my favourite
plataform game for MSX is "Thexder". Thinking about it, MSX is
In my opinion, Thexder (like FireHawk) isn't a platform game. It is
something "strange" and addictive, an excelent game, but not a platform
game.
"weak" in plataform games. I tried to remember how many there
were, and could only count a few ("Choro-Q", "Crusader",
"Gojira Kun" [Godzilla], "Mr. Gordon Goody", "Majou Densetsu II
- The Maze of Galious" and so on). There are also some very
The best of all that you mention is The Maze of Galious. It has an excelent
playability, an immense scenario, good graphics, and some elements of RPG
and adventure game.
But there are other platform game, at least in the spanish market. For
example, Abu Simbel Profanation (it was good), Temptations, Bestial Warrior,
StarQuake, Game Over, ...
playable in the Disc Stations. Except for a few, like "MD2",
"Hundra" and those of Disc Stations, most have a terrible
playability, including the "Jet Set Willy" series (sorry, but
it is the truth).
Well, I have played it a few times, and I think is good. It isn't excelent,
but it is good.
And... why do you say "it is the truth"??? It seems that you know the
truth!! Everybody knows that the truth is out there. ;-)
A plataform game don't have to perfectly
simulate inertia, wind speed and so on, but must give options
to the player to actually _play_ the game. For example, "Akumajou
Dracula" of the Super Famicom don't allow jump control while the
character is in mid-air (like "MD2" does), but you can still
control other "variables", like the whip, making the game very
playable and enjoyable. On the other hand, "Actraiser", also
for SFC, is simply annoying: like "Akumajou Dracula" it doesn't
allow mid-air jump control, but also doesn't give the player
any alternative (there are only one possible movement for the
sword in mid-air, and it is too slow). The only thing that
could make it just a bit more annoying is inertia simulation,
exactly the factor present in "Jet Set Willy" that makes me reach
the conclusion that it is "boring". Well, as you see, I never
criticize without a solid argumentation basis, what in no way
should stop people of trying those games I don't like (everyone
must breed its own opinion). Mostly because the games I like form
a very short list...
IMHO, there aren't at all solid argumentations. Inertia? Hum... You speak
like a Quake player speaking about the phisical forces that actuate in the
3D world!
All the things that you mention are details. There is not a mathematical
expression of "fun", then, a platform with no one of the qualities that you
mention can be good.
Why I say this? Because you can't affirm if a game is good or bad. You can
only say that you don't like it!
And, take in mind a curious thing: There are some Jet Set Willi fan clubs!!
--
Antoni Burguera Burguera
E-mail: [EMAIL PROTECTED]
--
9D-La Novena Dimensio
http://www.geocities.com/Area51/Dimension/9812
--
MallorcaWeb
http://www.mallorcaweb.com
http://www.mallorcaweb.com/sessalines
--
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
NestorBASIC suggestions
About NestorBASIC: (^ ^)Y The user interface is not very easy to use, but I think, that it can't be done better without XBASIC sources or if we want it still to be in More people also said it to me. And I can only answer the same as you said: Do you want XBASIC compatibility? Then there is no other way to perform a BASIC extension. small size. So, I have to print that huge manual, if I really want to use these new features... Anyway I think, that I'm gonna use this in Also, more people said to me: What a hugue manual! Answer: NestorBASIC has 80 functions, and I must explain all of it! But I don't expect that NBASIC users will use ALL the functions! I put all-purpose functions, you just use the ones that you need. my next demo as a glue. This is perfect for that purpose,at least in my case, because I can't proggram anything else that BASIC and ML. :-) Remember that NBASIC allows you to execute ML routines stored in a RAM segment, and after that, to return to BASIC. Maybe this feature will be useful for you. So, again my personal thanx will go to you. You're very welcome! 8-) You wanted to hear opinions, so now it is done. Next there is new ideas, that you also wanted to have : Oh! Ideas! You are almost the first one!! Please don't forget also to report any failures you can found! I can found some by myself (for example, when you try to compress a graphic while a music is being replayed the system hangs X-( But I need the help of the users! Maybe you can add a memory use routines also for computers, that have 192Kb VRAM, because there is no too many other proggrams, that can use this feature, but there is quite a many computers that has expanded VRAM. Maybe also 512Kb of GFX9000 can be useful for data storeing. Maybe there is someone reading this, that can give techical docs. Yes, it is a good idea to support this extra 64K VRAM with the basic functions pack. About GFX9000, I think it is better to make a separate functions module, and use it with the segment stored ML routines execution feature (what a long, ugly name! 8-). How about adding automatic uninstall, when exiting to DOS, by doing your own _SYSTEM handler routine (for example in SUPER-X) This maybe does not work, if you are using external DOS2, that is plased before RAM, but anyway it will increase safety. What do you mean, to pacth _SYSTEM statement or to add an USR for exiting DOS? If you go to BASIC, and load NBASIC or some other "bad behaving" basic extension, that is using CALL commands and then return to DOS by typeing _SYSTEM everything is Ok, but when you go back to BASIC, and try to write _SYSTEM or any other CALL command, your computer will hang, because it tryes to execute proggram, that was in address #4000-#7FFF before DOS used it. There is no probblem, if this extension is in ROM. But remember that NBASIC don't uses CALLs! Hey, wait... yes, actually the _TURBO ON/OFF. You are right. Solution : (...) I will place this piece of code in the uninstallation code of NBASIC. Thanxs! If you want to be 100% sure, that this probblem does not appear, then you can run this proggram for all RAM slots, but I don't think that it is necessary. NestorBASIC places XBASIC in the primary mapper, as usual. Greetings / Groetjes / Terveisin : ...Chas Gracias! ;-) --| About... |--- | | | Konami Man v23.10 | | | |Developped by | | Antonio Soriano | | Concepcion Vilchez | | | |(c) 1974-1997 | | Soriano Family Ltd. | | | |This humanware | | is itself-domain| | | | Constantly updated | |Please send bug reports| | and improvement suggestions | | to [EMAIL PROTECTED] | | | | | | | OK || | | - MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Breaking the 32Mb/partition limit
About all this 32Mb limit... I found your message very interisting! Let's comment it. The current reason for the limit is because we only have 16 bits to specify the sector number. As each sector is 512 bytes at the moment, the maximum partition size we can access is 65526 * 512 = 32 Mbyte Perfect. You could want to change the sector size, but I don't think this will work. To change the 512 bytes sector size? I never think on that! Or maybe you refer to change the number of bytes used to make sector numbers? Sector buffers of 512 bytes wouldn't be enough anymore, so the internal MSX disk basic structures would have to change. If the problem is the sector buffers, more mapped memory can be used. But this is managed by the DOS, and not by the disk BASIC, I think. Better would be to change the sector number from a 16 bit integer to a 32 bit integer. It would probably take the following : This was my initial idea: not bigger sectors, but more sectors! - Add an extra entry to the disk interface. For most SCSI interfaces and IDE interface there already is one. This is the easy part, I think (if hard disk controller has SRAM, like Mega-SCSI, or flash-eprom like IDE) - Change some routines to calculate sector numbers. Since 16 bit sector number are the only option in the MSX standard, these routines probably won't return a 32 bit value. So you would have to add extra math routines that are somewhat bigger. We are treating integer number. This is not mathematically complex, even if 32 bit numbers are used. It might be better to rewrite all FAT-12 routines to FAT-16 routines. But then you have to write routines that check what FAT routines have to be used. Yes, and information about the FAT type must be written in the boot sector of the disks. So, maybe a new FIXDISK will also be needed. In my oppinion it would be even better to define a new kind of driver system... You catch it! Change MSX-DOS so that the BDOS entry's don't use the MSX standard, but patch it to use a common driver and remove all the sector based routines. But remember that some software (for example, japanese games) makes direct access to the disk access routines of the disk controllers. If this access is done through the routine at #144 in main BIOS, no problem, because there is a jump to a hook. But I found in some cases a call to routine #4010 in the disk controller slot... This driver could have the following entries : Hey, you have developed almost a complete system! Yes, the driver must have all of these functionalities, and the ones needed to be full DOS 2 compatible. This looks very simple, but really, it isn't. You have to define a standard to make it really work. It will be a long work, but it is possible! It could work like this : (...) I don't know if this is clear enough. Otherwise I will think of something when I have some time. I think it is clear enough. It's just an idea... Really, a good idea! Might be that the creators of MSXCDEX know how to patch the BDOS functions, as they probably have done that. It would be even greater if they already have made this kind of software for non-CD-ROM devices. I already asked Taro Kashiwazaki about his methods of patching BDOS. I'm waiting his reply... --| About... |--- | | | Konami Man v23.10 | | | |Developped by | | Antonio Soriano | | Concepcion Vilchez | | | |(c) 1974-1997 | | Soriano Family Ltd. | | | |This humanware | | is itself-domain| | | | Constantly updated | |Please send bug reports| | and improvement suggestions | | to [EMAIL PROTECTED] | | | | | | | OK || | | - MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Computermeeting Tilburg 24 april 1999
Aan geïnteresseerden en belanghebbenden. Tilburg, januari 1999. Betreft: Computer-meeting Tilburg 1999. Dit is de laatste mogelijkheid om in te schrijven voor deelname aan de computer-meeting in Tilburg, welke gehouden wordt op ZATERDAG 24 APRIL 1999 van 10.00 tot 16.00 uur. Ook dit jaar zijn verenigingen, particulieren en bedrijven van harte welkom en zullen we ook weer internationaal zijn. Er wordt zelfs over deelname uit Brazilië gesproken. Dus Tilburg gaat zeker door !!! Dit keer niet in de Bremhorsthal, maar in het Wijkcentrum De Schans. Dit is geen buurthuis, maar een gebouw, dat zeker qua vloeroppervlakte evenredig is aan de Bremhorsthal. De verschillende verdiepingen zijn per lift bereikbaar. Aangezien de huurprijs minder is dan de Bremhorsthal kunnen wij de kosten ook laag houden. De kosten bedragen per 3 mtr. slechts fl. 30,00 en de toegangsprijs zal fl. 2,50 p.p. zijn. Ook degenen die reeds ingeschreven hebben verzoeken wij alsnog bijgaand formulier voor 28 februari a.s. in te sturen, per fax of E-mail mag natuurlijk ook, zodat u zeker van een plaats bent. Stuur tijdig in want vol is vol. Door het wegvallen van MCCM is het belangrijk dat u in uw omgeving bekend maakt dat deze meeting in Tilburg weer gehouden wordt en deze te promoten. Het Wijkcentrum De Schans is gelegen aan De Schans 123 te Tilburg-Noord en met openbaar vervoer (lijn 44-45 - halte Vlashoflaan/Griegstraat) goed bereikbaar. (Er rijdt dit jaar GEEN GRATIS BUS). Organisatie Internationale Computer Meeting 1999 Bartokstraat 196 5011 JD TILBURG Telefoon: 013 - 4560668 of 013 - 4681421 (na 19.00 uur) Faxnr.: 013 - 4560668 E-mail: [EMAIL PROTECTED] RESERVERINGS-FORMULIER voor de COMPUTER MEETING 1999 Tilburg. = Plaats, ... Datum , //. Ondergetekende: vereniging / firma / partikulier (doorhalen wat niet van toepassing is) verzoekt voor hem/haar te reserveren: . stuks stands van 3 mtr. à fl. 30,00. Naam (privé/vereniging) . Adres : Code/Plaats: Tel.nummer : Contactpersoon : ... Handtekening: ... I.v.m. onze publicaties is het belangrijk, dat u vermeldt welke artikelen u verkoopt / demonstreert. Indien u uw informatie op wilt laten nemen verzoeken wij u om uw gegevens hierover samen met uw aanmelding op te sturen. ... ... ... Het verdelen van de stand's geschiedt in volgorde van aanmelding en betaling. DE BETALING MOET VOOR 27 MAART 1999 IN ONS BEZIT ZIJN, ANDERS VERVALT DE RESERVERING !!! Postbank 5728841 t.n.v. CGV Karmijnstraat 18 5044 RD Tilburg Onder vermelding van "Computer Meeting 1999" en de naam waaronder u ingeschreven hebt. De deelnemerskaarten (3 per kraam) worden begin April 1999 toegestuurd. Organisatie Computer Meeting 1999. Bartokstraat 196, 5011 JD Tilburg. Tel. 013 - 4560668 of 013 - 4681421. (Na 19.00 uur) Fax. 013 - 4560668. Email: [EMAIL PROTECTED]
Re: JoyNet serial transfer routines
At 07:00 PM 10/12/98 +, you wrote: I think you are both mistaken here. In synchronous communications, the exact point in time at which the data signal(s) is sampled, is determined by an 'extra' signal, an other signal, and with that, the data stream is SYNCHRONISED with that other signal. What you call an 'extra' signal, is just as much part of the signal as the data signals are. Dependant on the encoding, it may not even be possible to say "these bits are data and these bits are timing". Take for example the encoding I proposed on this list a while ago: There are 2 signal bits: D0 and D1. Flipping of D0 means "a 0 is transmitted". Flipping of D1 means "a 1 is transmitted". Since the timing information is part of the communicated message, the sender and receiver need not be synchronized. If such an other signal is not used, or not present, the data stream can NOT be SYNCHRONISED with that other signal, and thus becomes an ASYNCHRONE communication method. In this case, it is usallly a fixed timing scheme that determines when bits are to be sampled. Such a fixed timing scheme is usually referred to/derived from/related to as "baudrate". This is the common way used for RS-232 communications, and the same goes for MIDI-connections (also Asynchronous). Because the signal itself doesn't include any timing information, you do need external synchronization. I'm not sure the reasoning I used above is the one used for the name-giving. But I have had a couple of courses at the university about asynchronous computing and communication, so I know what's asynchronous and what isn't. Besides: if JoyNet only standardises the cable, than that leaves the programmer free to choose for a synchronous or an asynchronous communication method. It does. I just strongly recommend an delay-insensitive asynchronous communication protocol, because that will give far less trouble. For example, it is insensitive to cable lengths and it will run at any clock speed. If the number of connection lines in the cable is such, that no extra lines besides the data lines are available, then that would automaticly force asynchronous communication to be used. If not, both methods could be used. There are two bits available for sending, which is enough. -For networkgames, SPEED is crucial, and error-checking not that important, or not at all There are two speed factors that are important: 1. the delay before actual data is sent 2. the time it takes to send the data Point 1 is caused by the fact that the processors of both the sender and the receiver need to actively participate in the transfer handshaking. The sender has to wait until the receiver is ready to start the transfer. If the amount data you have to send is small, point 1 is far more important for the performance of your game than point 2 is. Transmission errors in games are *not* funny random effects. They can ruin the game in progress. -For data-transfer, speed is not THAT important, and error-checking might greatly improve reliability. I too think reliability is important. But you suggested 32 bit CRC without any proper argument why what error detection would be the right one. Besides, error detection depends on message size as well. One 32 bit CRC per kilobyte offers far better error detection that one 32 bit CRC per megabyte. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Graphics Designer...
Hello, All of you know (I hope) that we are making a nice magazine called XSW. Till now me filled the cover with little pictures and text about the contents of the magazine... So boring... To make the full color cover less boring, we are looking for Graphic Designers who like to draw pictures for the cover! Our only wish is that they put the text XSW in it! You can draw what you like, use as much colors as you. You can use allmost every PC-format (GIF, PCX, JPG...) and even MSX screens (5,7,8 and 12)... Send us your drawings, when we use them, you will get a free issue of the magazine! --- e-mail: [EMAIL PROTECTED] --[ MARI ]-- -- Visit XSW-Magazine's HomePage at: http://www.tip.nl/users/m.broek -- M.H.M. van den Broek Molenweg 17 5342 TA Oss 0412-630653 / 0654-642288 (till 31/08/98) --
Re: Network
This sounds promising! with the right software it should be possible to make a drive mapping to the pc. The software should probably be written like a disk rom. This is the same as a ramdisk for dos1 does. One more comment though, why not make the single port version first? I don't think there are many people (except mr. Witkop) who have more than two msx computers. I have a sony rs232 which contains the bios, so perhaps this is usable. The problem is again the software, I need some kind of sever program for the pc, and a client program for the msx. I do know some assembly for the msx, and I know how the diskrom principle works, but I don't get a clue how to program the rs232. Perhaps Erik de Boer knows this. Philip At 19:38 13-11-98 +0100, you wrote: Yes, I'm currently working on something like this. I came up with the idea of making a bi-directional interface for the MSX. It had to be 8-bits. And since the parallel port of the pc is also bi-directional and 8-bits we planned to develop a bi-directional printerport for the msx. Erik the Boer ([EMAIL PROTECTED]) made a layout of a printed circuit board for me but all is stil in it's early development stages. The board has to modes. One of them generates an interrupt on #38 whenever a byte is sent. The other one is withoput the interrupt. Both modes are latched so you don't have to poll anything which saves cpu-time. Now the plans have changed somewhat. Because I thought it would also be fun if you could also link all your msx-es together. But that would mean that one MSX had tot have two printerport cartridges. And since most MSX-es only have two external cartridge slots this doesn't leave any room for extra harware like an scc cartridge or slotexpander. Another problem was that both cartridges couldn't use the same I/O adresses. They had to have a dipswitch in order to select another range of I/O adresses for one of them. So i'm redesigning the stuff. The new plan is to create one cartridge with two parrallel printerlike ports on it. This saves one slot but the cartridge does become bigger. You can use it to either link your MSX to the parrallel port of your PC, or link your MSX to another MSX, or both;) I was writing a driver for the PC which makes the PC the slave so you could access the harrdisk directly with some kind of file transfer protocol. I don'y know how to make the MSX see your PC as another drive though. But I'm still some months away of finishing this project because I also have a night job and have to go to university in the daytime. So here's what you can do on short term; - Connect the serial port of the pc to an rs232 msx cart. But then your problem would be the software for msx. There isn't any exept for bbs's and thephilips rs232 doesn't have an built in rs232 rom. So you can't use those system calls either. - Connect an MSX joystick port to the parrallel port of your pc. You can do 4-bit biderectional parrallel transfers this way. You'll have to write the software yourself. But both the msx joystick port and the pc parralllel port are well documented. Good luck! Gerald MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
[257 RobotZ] All robots need a number and it should be not too many bits when communicating. Agreed. One byte as ID should suffice, which makes 256 robotz... Therefore, you can have 256 external robots plus one for the computer itself. No, 255 external IDs, plus one ID for the computer itself. When it wants to send data it has to have a means to make the others be able to identify him. You don't need to send the data of the robot that's listening. It knows what it sent... after a minute of puzzlement Ah! I C! Let me try to explain what I think that you mean. All computers are connected in a ring (Joynet basic principle number 1 :-)) Communication takes place in one direction, lets say from right to left. At the start, some fuzzywuzzy takes place to determine the size of the ring - lets say N. Then each computer sends its own data block (to left), reads N data blocks, (from right) and sends them all (to left) except for the last one which is the data block sent by its left neighbour. Then it can send it's own data block again and the next N-1 blocks recieved etc, etc... In contrast to my idea, where each computer gets a globally known fixed ID, you work with 'relative' id's in this method and then you can connect upto 257 comps. Clever! Anyway, I think that a competition of 256 or 257 robots will be very close to impossible to play. You'd have to have a *huge* playing field to make it a bit interesting, which has to be updated and kept consistent over all connected computers... So what? Can't you write two robot-programs? :-) Hehe... It will be boring after a while. If you make the possibility to play against the computer (not using joynet), you could also spread robot-programs. When robot-programs are spread you can take the program of another and your own to play agains each other. No need to have a real 'computer' player. Or do we have a slight different opinion of 'computer player' and are actually saying the same? It might even be possible to encode it, so that you can't read the source to see how to beat it, but that would be quite hard. That's why leaving the programming language open to the programmer is so good. Disassembling compiled TurboPascal or MSX-C code is quite hard... On the other hand, if the source code of another program can help you to improve your own program, you can get a real evolution of programs... [idea!] It is possible, of course, but how do you check if a language does not cheat? A language can't cheat. Only the program (sorry for the lecture :-)) To your Q: You can't if you don't use a special purpose robot programming language. But with a well defined set of playing rules you can limit the possibility of cheating. Anyway, when I finish the game, I'll make the communication protocol public, Let's first try to define the _exact_ playing rules. Then it's easier to define the communication protocol. I'll sleep on it this weekend :-) so everybody is free to make his/her own language. I think you didn't quite understand what I meant: I was talking of _using_ a programming language to program the robot , not specifically _making_ it. You only define the _playing rules_ and each and everyone can make a program in any language (C, TP, asm, BASIC, COBOL) that obeys the rules and tries to win... Eric MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Would you like to have a bit faster MSX for free ???
On Mon, 5 Jan 1998, Konami Man wrote: Well, maybe you have allready MSX tR, that is quite a fast, but if you use BASIC, XBASIC, POWER BASIC or NESTOR BASIC proggrams then I can give you even some more speed for you to use... Hey, thanx you for treating my NestorBASIC as a standard!!! ;-D By the way, you already tested it? Oh, yes now I have, but not very mutch yet. Anyway here is your doom: The user interface is not very easy to use, but I think, that it can't be done better without XBASIC sources or if we want it still to be in small size. So, I have to print that huge manual, if I really want to use these new features... Anyway I think, that I'm gonna use this in my next demo as a glue. This is perfect for that purpose,at least in my case, because I can't proggram anything else that BASIC and ML. :-) So, again my personal thanx will go to you. You wanted to hear opinions, so now it is done. Next there is new ideas, that you also wanted to have : First : - Maybe you can add a memory use routines also for computers, that have 192Kb VRAM, because there is no too many other proggrams, that can use this feature, but there is quite a many computers that has expanded VRAM. Maybe also 512Kb of GFX9000 can be useful for data storeing. Maybe there is someone reading this, that can give techical docs. Second : -- How about adding automatic uninstall, when exiting to DOS, by doing your own _SYSTEM handler routine (for example in SUPER-X) This maybe does not work, if you are using external DOS2, that is plased before RAM, but anyway it will increase safety. Last : This is probblem, that I have explained also for C.P.U. and this feature is going to be fixed in MSX-DOS 2.42 anyway I think, that this should be your proggrams job to fix : If you go to BASIC, and load NBASIC or some other "bad behaving" basic extension, that is using CALL commands and then return to DOS by typeing _SYSTEM everything is Ok, but when you go back to BASIC, and try to write _SYSTEM or any other CALL command, your computer will hang, because it tryes to execute proggram, that was in address #4000-#7FFF before DOS used it. There is no probblem, if this extension is in ROM. Solution : We have to reset CALL flag, so that when DOS is loaded again Basic does not try to execute any CALL commands to same RAM slot before that extension proggram is loaded again. This can be done, when you uninstal NBASIC. Here is proggram, that fixes this probblem. I have this in my REBOOT.BAT LD A,(#F342) ;GET SLOT ID FOR RAM #4000-#7FFF LD B,A ;CALCULATE ADDRESS FOR CALL FLAG AND 3 RLCA RLCA RLCA RLCA LD C,A LD A,B AND #C ADD A,C LD C,A LD B,0 LD HL,#FCCA ADD HL,BC LD (HL),0 ;RESET CALL FLAG RET If you want to be 100% sure, that this probblem does not appear, then you can run this proggram for all RAM slots, but I don't think that it is necessary. Greetings / Groetjes / Terveisin : ,_. _=_=_=_=!_MSX_!=_=_=_=_=_=_=_=_, ! A1ST ~--- - I ( o o o o o o )i /`, / .::;::; ., / :::.:.:.::::!. -=- `, ~== NYYRIKKI : [EMAIL PROTECTED] --| About... |--- | | | Konami Man v23.10 | | | | Developped by | | Antonio Soriano | | Concepcion Vilchez | | | | (c) 1974-1997 | | Soriano Family Ltd.| | | | This humanware | | is itself-domain| | | | Constantly updated | |Please send bug reports | | and improvement suggestions| | to [EMAIL PROTECTED] | | | | | | | OK || | | - MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: some y2k trivia 'n stuff..
Hi all, Claudio Massao Kawata [EMAIL PROTECTED] wrote: (..) Alwin Henseler ([EMAIL PROTECTED]) wrote about the way the leap years are calculated (once each four years, except once each century, except once each four centuries). I already knew that (many years ago, I needed a reliable calendar program for an "time-travel" adventure). He called it a "ridiculous system". I don't think it is ridiculous. I meant the way you have to calculate it, this system itself is genius indeed. To keep in sync with the sun planets, 1 year would have to be something like 365,24 days (don't know the exact value, and this is not really a constant either, but shifting slowly as well). So, add a day every 4 years, and average year becomes 365,25 Hmm, to much...take out this extra day once every 100 years. Hmm, a bit to little...add it back in every 400 years (you calculate the aproximate value, which, you're right, is still not exactly on the dot, but close). Genius indeed, considering this was figured out back in the year 15xx (I doubt it was that pope himself who did it, though). Why I mention all this? Because MSX don't have a 2000-year-bug, but a 2080-year-bug. Wrong... Whether or not a system is affected by a year 2000-bug, or similar bugs (other systems use different ways of counting time, and suffer similar bugs, but on different times), is a combination of factors: -Hardware: MSX2 up uses Ricoh RP5C01 compatible clockchip, which DOES count wrong every 100th year (even Ricoh itself says so), because it simply takes EVERY 4th year as a leap year. In the year 2000 this just doesn't show. -System software -BIOS -Basic -DOS date functions Just showing that the date rolls over correctly from dec. 31, 1999 to jan. 1, 2000 says something, but not that much. Showing that you can store a date beyond 2000, and retrieve it correctly, doesn't say everything either. You can only say for sure that this is processed correctly, if you analyse the exact functions code involved, looking at what range of numbers are processed, how these are 'clipped' etc. Did you check all the BIOS/diskROM/DOS code involved? Neither did I. So that's not an 'okay', but rather a 'don't know, looks okay' -Application software: There's gotta be thousands of MSX programs, and probably hundreds or more dealing with dates in one way or another. I would simply say here: SURELY plenty of programs that don't get it right, so bugs are in here as well. All this ofcourse only with respect to the year 2000, take a broader view, and you'll surely find more of such problems (like the year 2079). (departing from MSX here...) And this is no little software-update problem either. Some institute estimated that all this work to get year-2000-ready will/has taken so much effort, that it will lower economic growth with at least a full percent (that's globaly, or for most industrialised nations). Not doing this work to check and fix systems, would probably have a similar effect because of all the problems that would result, when non-checked system do go wrong. That makes the y2k-problem a problem with at least a similar magnitude as the earthquake in Kobe, Japan (you know, economists were up in arms about the economic effect when this happened). I'm not scared the world will come to an end as some might believe, but calling al this plain 'paranoia', is equally far from the truth. More trivia about dates: the years start from 1, not zero, as most people think. It is true There is no zero-eth year, an error many people make Sure there were years before 1!... I think the year '0' would commonly be referred to as 'the year 1 before Christ', so: 3 before Christ 2 before Christ 1 before Christ the year 1 the year 2 . . the year 99 (1st century) the year 100 (2nd century) Sure, technically the 2nd century would start only in the year 101, and the 21st century in 2001, but who cares? That's just a matter of convention. If everyone feels a next century started when 19xx changed to 20xx, then it did, didn't it? Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: New joystick communication standard proposal
On Fri, 21 Aug 1998, Manuel Bilderbeek wrote: I can imagine a system like this that would have far less problems: 0V means "0" 5V means "1" When the level goes from 0V to 5V, at 3V the bit flips to "1". When the level goes from 5V to 0V, at 2V the bit flips to "0". Does anyone know how things work in the MSX ICs? At my electronics course, I learned there are conventions/rules/standards for this. The level for 0 and for 1 is in these conventions. The most used conventions are CMOS and TTL. It depends on which one is used ofcourse. CMOS is 'stiffer' than TTL. But I don't know what the limits are exactly. CMOS chips has a transfer curve infinitely differentiable, i.e., there's no abruptous transitions. For example: Output ^ | |... | .. | . | . | . | . | . |.. | ... | . --- Input This means that, if the source is 5.0V, the inversion voltage of a CMOS inverter is exactly 2.5V (theoretically). But if you want to know what happens if you apply 1.5V to the input of a CMOS inverter, I can say that an approximated value is 3.5V. So, for digital signals, it's strongly recommended that the low level doesnt' exceed 1.0V and the high level doesn't be below 4.0V, supposing that the source (VDD) is 5.0V. In TTL circuits, the standard says that: source voltage: 5.0V +/- 10% maximum low level input signal: 0.8V minumum high level input signal: 2.4V But what happens when you apply a signal between 0.8V and 2.4V? Everything can happen! In this range, each integrated circuit from each manufacturer can do what it wants! It's unpredictable. To solve this problem there are an special family of TTL integrated circuits called "SCHMITT TRIGGER", that implements an special transfer curve called "HYSTERESIS". The phenomenom of hysteresis was first discovered in magnetic materials, and after the concept was applied in conversion of analog signals to digital. It works like Manuel explained, and below there is a transfer curve of an SCHMITT TRIGGER: Output ^ 5V | | .. | .. | .. | .. | ^V | .. | .. | .. | .. 0.4V| . --- Input 0V 0.8V 2.4V5V The arrows in the graphic above show that this graphic can be read only in the indicated directions. Let's interpret this transfer curve: when the input is very low, the output is high. Increasing the input voltage until lower than 2.4V the output will keep the output high. If the input becomes higher than 2.4V, then the output will go to low level, and if you decrease the input of a small voltage, the output will keep low! This means that the transfer curve is not linear and not continuous (so, not differentiable). Increasing the input until 5V will keep the output low. Now, decreasing the input voltage until higher than 0.8V the output will keep low. If the input becomes lower than 0.8V, then the output will go to high level, and if you increase the input of a small voltage, the output will keep high! This is the principle of hysteresis: when a transition happens, the input voltage should "come back" a big value! When you asked "Does anyone know how things work in the MSX ICs", you mean externally to the chip or internally? I think I explained externally, but if you wanna know internally, it's a long long story! PS: It's obvious that the network cable MUST HAVE a ground! And 9600 bauds if only 4 times faster than a tape. So, anyone should create a network cartridge for MSX. And why not a wireless network? Best regards! Marco Antonio MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Counting
Now we're going really off-topic : By the way, although in "real life" most things are (unfortunately) numbered from 1, building stories are numbered from 0. But somehow floor zero is given a special name (ground floor or something like that). You're wrong. In English, the ground floor is the first floor. Only in Dutch you start counting at zero! :-) At Spain we start also by the ground floor, and also there are sometimes the 'principal' or the 'entresuelo', sometimes even both, and then the first floor and... ...and, and what the heck! What's this??? X-D A MSX Mailing List or a 'sketch' for a chapter of Sesame Street??? X- (Who the heck is going to sing us the song of 4? X- ) Just with the relation of floors... I have heard some rumours that in some large buildings the 13'th floor doesn't exist! So, we should start counting at 1, we should stop counting at 12 and continue counting with 14 But I don't think this counting should be standarized or so, it's not that important. Some programs are better implemented when counting starts at 0, and some like to start with 1. Please, end this discussion;-) Greetings from Erik Maas p.s.1 About the year 2000 problem I received a message from a friend, sorry it is in dutch only p.s.2 Please do not send any reaction to the mailinglist about this message [ Dutch mode on Please???] Wij zijn bezig met enkele personen om een nieuwe jaartelling cq. tijdsindicatie te genereren. Deze zou moeten worden ingevoerd op de overgang van 1999 naar 2000. Deze overgang wordt gezien als de eeuwwisseling maar is dat eigenlijk niet. Het jaar 0 bestaat namelijk niet in onze jaartelling dus de eeuwwisseling is eigenlijk van 2000 naar 2001. Dan is dit niet eens op de overgang van 31 december naar 1 januari, dit omdat sommige geleerden een rekenfout hebben gemaakt bij de invoering van de jaartelling, dit heeft men proberen te corrigeren door een eeuw of wat geleden een paar weken over te slaan. Deze correctie berekening is ook fout gelopen. Dus: op 2000 is het GEEN 2000 jaar geleden dat de oorsprong van onze jaartelling plaatsvond. Ook het aantal maanden in onze jaren kloppen niet, December de 10de maand genaamd is onze 12de maand, dit komt omdat de keizers Julius en Augustus hun maanden hebben toegevoegd aan de kalender. Tevens zitten we met onze klok, die afstamt uit een 60 tallig rekenstelsel, terwijl wij allen tegewoordig een tientallig stelsel gebruiken. Al met al klopt er dus niets van. Daarom willen wij tot een nieuw stelsel komen, er zijn al enkele voorstellen, een definitieve uitgave moet er nog komen, alle op en aanmerkingen zijn welkom: 1) Het moet een decimale tijds telling worden. 2) We gaan uit van de dagen die we opdelen in eenheden. 3) Jaren worden anders gedefinieerd, Waarom 364 dagen in een jaar en af en toe anders, laten we 1000 dagen in een jaar nemen. 4) Het begin van de telling wordt wat wij nu noemen 1 Jan. 2000 we noemen het dan de tijd voor/na de "Big Crash", hierdoor kunnen we de afkorting BC toch blijven gebruiken. 5) De tijdstelling cq. jaartelling wordt logaritmisch, het gehoor is immer ook zo, ons gevoel voor tijd zal dus ook logaritmisch verlopen. VB: naarmate we ouder worden lijkt de tijd te vliegen dit kunnen we dus opvangen met een andere schaalverdeling. 6) Door een logaritmische verdeling zijn we ook van het jaar 0 probleem af, deze bestaat dan gewoon niet. Een en ander wordt nog onderzocht, een ding staat vast: de programmeurs die het milennium probleem oplossen zijn hier niet blij mee, kunnen ze weer opnieuw beginnen. Eigenlijk zijn de programmeurs iets aan het oplossen wat niet bestaat, het milennium probleem, de overgang van 2000 naar 2001, bestaat niet. Gelukkig hebben we ook programmeurs die het jaar 2000 probleem oplossen. Ideen voor een nieuwe telling zijn van harte welkom, Arno en zijn belgium collega's. MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Speeding up Interrupts...
Response of own-interrupt-expert Grauw... If you are programming a game or so I'd suggest you switch RAM in slot 0 (who uses the bios?) or use another interrupt-mode (IM 2, if I'm correct. Don't forget to switch back to IM1 afterwards!). Yes, it's IM2. But it's not that easy to use. IM2 works like this: - interrupt register contains high byte of entry in interrupt vector table - at the time of an interrupt, the data bus contains low byte of entry in interrupt vector table In the interrupt vector table, an address is read and that is where will be jumped to (begin of interrupt handler). Most MSX systems have #FF on the databus at the time of an interrupt, but I heard (from one of the NOP members) that some cartridges mess with this, so you cannot be sure. The safe way is to store the same value in a 257 byte long range like #4000-#4101 and set the I register to #40 in this example. If the value stored is #41, #4141 will always be the address. But I think a custom BIOS is much easier to use, unless you plan to use BIOS routines. :#FD9A: called on every interrupt which occurs, : normally not used by the system, only some special software. : - there shouldn't be problems if I won't call this old entry Used by the newest version of MBWAVE and its basic-replayer. But your custom BIOS can call the MBWAVE replayer directly, if you use it. Also, the stop of the drive isn't really 'good' when you call it 256 times after a diskoperation, it will STOP. Immediately after every disk-access. Which isn't that nice... That's true, you have to stop the drive after every block of disk actions. Another thing to remember: if you need disk swapping in your game and you run under DOS2, be sure to invalidate the disk buffers before every block of disk actions. There is a DOS2 call that does this. Otherwise, the disk change will not be detected on most machines. On non-turbo-R, DOS2 'detects' disk change simply by counting the time since the last disk action. It is assumed that no-one can swap a disk in less than a second (or another small time interval). If you stop calling #FD9F, the counting stops and DOS2 can think the last disk action was very recent but in fact several minutes have passed since. :What is your opinion? Will I be in troubles by removing this two calls? No troubles, I think, but some things might not work correct anymore. Isn't that a form of trouble? In my own interrupt-routines, I always call #FD9A and if it's an VDP-interrupt I also call #FD9F, fill in the key-table, increase JIFFY and do some game-related things. But I dunno if you can speed-up the interrupt that much. Yes, I know your thinking... You hope to be able to delete some PUSH and POP-instructions at the beginning. The real speed gain comes from: - Not filling the key-table: games are usually interested in only a few keys, not the whole keyboard. Besides, why not read the keyboard directly from your game? - Keeping VDP status register 2 enabled all of the time. Or register 1, if you use line interrupts frequently. This doesn't make your interrupt routine faster, but it can speed up your non-interrupt code. - Not decreasing the disk drive counter, which requires a slow inter-slot-call. - No writing to the joystick registers of the PSG. If you omit that, you will be able to use the JoyNet without disabling interrupts. So you gain speed not by doing the same in less time, but by doing less. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: JoyNet serial transfer routines
:I'm trying to develop a asynchone (or synchrone?) method to transfer data :between 2 MSX-computers (i.e. for games), using JoyNet. Advantages of this :compared to a fixed Baud-rate-protocol are that it runs on every kind of :MSX-computer, unlike its speed and available timers. Also, you won't have to :recalibrate each time after sending 10-20 bits. Both computers use the same :speed as the slowest MSX, and the slowest MSX _will run on its top speed_. :The main idea is that bith computers flipflop bit 3. : :Don't forget to mention that your game uses only 2 MSXes. Ummm... see above. :Other JoyNet :programs will work on larger numbers of MSXes. The bidirectional transfer :you propose is only possible if you connect just 2 MSXes. I am aware of that. But only 2 computers also means a very fast rate! :Every transfer is a send + a recieve, both containing 2 bits (and 1 :flipflop). : :Note that your scheme is not delay insensitive. If the clock (which you :call flipflop) arrives earlier than the 2 data bits, the old data can be :read instead of the new data, resulting in a transmission error. You do :have error detection, but retransmission is not as nice as avoiding errors. :Unfortunately, I don't think that a delay insensitive code exists that :encodes 2 data bits in a 3 bit signal. Why should a delay-error occur? First, the chance on it is very low for the MSX is very slow, second, _if_ it occurs, there is a reasonable chance that my CRC detects it (when too much CRC-errors occur, an error is given and transmission is interrupted). And third, that delay-error can, to my opinion, only occur if you use very different kinds of wire in the cable. For instance, a 1.5mm wire for pin 8-3 and a 0.2mm wire for pins 1-6 and 2-7... :In the case of one computer sending, you could also make the other computer :send garbage of equal length as the real data. That might make your :routines simpler. It even doesn't send garbage. It just ignores it. :If you really want to make some :network-programs, which will all have to be able to 'understand' eachothers :transfers, then you might develop some standard PROTOCOL (which is not :specified in the JoyNet standard. : :Such a use would require a TSR, because even if one computer is currently :not engaged in a network transfer, it will have to forward messages from :other computers. That TSR could best be made as part of a driver. :But even then, it might be easier to standardize the driver interface and :still leave to protocol to the implementer of the driver. As long as all :MSXes on the network use the same driver, there is no problem. :And standardizing the driver interface allows other network hardware as :JoyNet as well. For example, the EPP cartridge Greg was working on. There should be made some utility calles Putrough.com or so which non-stop reads and sends the data from and to the joystick-port again (this can be interrupted by pressing ESC or so). If you have, for instance, a 3-computer ring then you can let two of them run the 2-player game and the other one run this program. The profit of doing this is that you don't have to de- and reconnect the cables in your network. :Ah, my homepage... almost forgot. :The Official JoyNet homepage: :http://datax.cjb.net/ : :Hey! Where did you get the "Official" qualification? Ummm... well, since my homepage contains the most detailed information about it etc... Anyway, I posted something about this once on the mailinglist and there was no objection. Anyway, I think it is good to have a 'official page'. Just to have all resources on one place, easy-to-find. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX PC local network
The PC part is probably easier than the MSX part, because you can use a language like Pascal or C to write the software and it will still be fast enough. Na, on MSX C or pascal or modula-2 will be fast enough I guess. The communication is rather straight-forward.. But transfer rate doesn't depend just on the speed of the software... Both ICs and wires introduce delays. Does anyone know how fast an average MSX joystick port is? Donno, but with a sync-signal it doesn't really matter. Don't expect very high bandwith, but we're not asking for that really (do we? As long as it works it would be nice :-) The joystick-port is implemented using the.. PSG! I don't think this chip is a wonder of speed, although it's possible to use it for digital audio at a desent quality. And take in mind that we have 2 joystick-ports, so we can have 5 data bits + 1 sync-signal. That'll be fast enough. Is the MSX parallel port bidirectional? If so, it would be ideal for data communication. No, it's not. It has only one input: printer on-line. We can use it's output capabilities 8-bit + strobe but that's it. Timing will become too hard. An other possiblity is, as I've mentioned before, the MIDI ports of PC and MSX, but this requires extra hardware. Also, MIDI will give you a low transfer rate. Enough for multiplayer games, too low for file transfers. And for multiplayer games the joystick connection is good enough. MIDI not fast enough you think? MIDI is 31.5kb/s, so faster than a 28k8 modem! There is a tetris-clone which you can play with 32 players at once, using the MusicModule as "lan". Does somebody know's how this is achived? I guess using the MIDI-IN and MIDI-OUT and a piece of software that relays the data for other computers. Using the interrupt-capabilities of the MusMod I guess it is possible to make a reliable network, in which you can hook up a PC quite easily. So, if somebody would think about transferring files using the joystickport and LPT port (perhaps even a toke-bus network using both joystickports? wha!) If you connect your joystick port 1 to one MSX and port 2 to another, you don't get a token bus network. The reason it's called token bus is that there is one bus for all nodes (computers) and the one who has the token is allowed to send. Oeps, token RING I mean.. Ok, this is what we have: -Connecting one PC to one MSX using RS232. That's possible and easy, but I guess I'm ot the only one without a RS232 interface for MSX (which are too expensive for me and for what I want to do with it) -Connecting one or more PC'es to one or more MSX'es in a real token RING (hehe) LAN using MIDI-IN and OUT. On MSX, a lot of people have a MIDI-port. MusMod, tR-GT and a bunch of others. Special drivers could be written for every module. On PC, this requires a soundcard and a (rather expensive) cable, however it's not THAT hard to make this cable yourself. Problem here is that there isn't a real standard for the MIDI-port used in all cards. I, for example, have a GUS PnP which is quite different from a SoundBlaster (fortunatly; SB stinks IMHO) although there are emulators. AND on PC we have Windows, which does provide a standard for using MIDI. I've looked at it, but it seems rather complicated to achieve raw data transfer in VC++5... Perhaps it's easier with Delphi. Using MIDI, it's possible to make a REAL LAN. Not too fast, but doesn't require rare or expensive hardware. -Connecting PC's and MSX'es using the PCs LPT port and MSXs joystickport. There is some kind of standard (could somebody give me the URL to the scheme?) for connecting 2 MSX'es and I guess it's not too hard to use a compatible standard using the LPT port. So, with standard hardware we can hook up MSX'es and PC'es together in a LAN. We only need some wires, plugs and a soldering-iron and ofcourse the software. Drawback is that on MSX this can't be interrupt-driven so you need polling which is not very suited in a token ring LAN IMHO. Looking at this, I prefer MIDI for data-transfer... Randy MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
[DUTCH only] MSX Beurs Nistelrode
Er wordt weer een MSX beurs gehouden op20 februari 1999 te Nistelrode. Lees het attachment! Groetjes Maico Arts MSX-NBNO MSX-VERENIGING NOORD-BRABANT NOORD-OOST - INFORMATIEBULLETIN - Hallo MSX-ers Bij deze stellen wij jullie/U op de hoogte van het feit dat MSX NBNO een echte MSX-Beurs gaat organiseren! Deze vindt plaats op zaterdag 20 februari 1999 in zaal Van de Ven, Laar 12 te Nistelrode. De beurs zal geopend zijn van 's morgens 10.00 uur tot 's middags 17.00 uur. Voor standhouders is de zaal reeds om 8.30 uur geopend Het is de bedoeling om de bezoekers zoveel mogelijk te laten zien op deze beurs. Hiervoor zijn in totaal 52 tafels beschikbaar. Elke tafel heeft de grootte van 1.20 x 0.80m. De prijs per tafel bedraagt 5,-. Het maximum aantal tafels per groep of deelnemer is vier (4) tafels. Voor maximaal twee (2) personen is een vrijkaartje beschikbaar. Wanneer meerdere personen per groep willen deelnemen, dan moet voor deze personen de bezoekersprijs, 2,50 per persoon, betaald te worden. Zodra de betaling ontvangen is, wordt de stand voor U gereserveerd. Betaling van de tafel(s) en de extra personen van de groep geschiedt door middel van overboeking op de giro of bank van MSX-NBNO. girorekening: 712.62.01 bankrekening: 1129.41.877 Voor bezoekers bedraagt de entree 2,50. Leden van MSX-NBNO krijgen (uiteraard) gratis toegang Wanneer u nog vragen of opmerkingen heeft, bel dan (van maandag t/m vrijdag tussen 19.00 en 21.00 uur) naar Maico Arts (0412-690757) of Richard Bosch (0412-638692), zij zullen u graag te woord staan. Of schrijf een E-mail naar: [EMAIL PROTECTED] of naar: [EMAIL PROTECTED] - Naam MSX-groep :__ Naam Contactpersoon :__ Adres:__ Postcode :__ Woonplaats :__ Telefoonnummer :___- Aantal tafels: Aantal deelnemers: e-mail adres :_ - Opsturen naar: Paraaf bestuur NBNO : _ I. v. Portugalstraat 9 5346 PJ OSS Naam MSX-groep :__ Naam contactpersoon :__ Adres :__ Postcode:__ Woonplaats :__ Telefoonnummer :___- Aantal tafels : Aantal deelnemers : Handtekening: _ e-mail adres: _
I: Win98
Leggete, ridete e diffondete
Read this, laugh for it and shed it
What is win 95 ? A great bug by Bill Gates ... :-)
Bye to all of You,
Salutoni a tutti voi,
---
Fronteddu Stefano
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://space.tin.it/computer/stfront MSX, Sardinia, Robotics, Friends
http://computer.digiland.it/1461 MSX Soft Tips Page
ICQ: 21401454
0338/3645458
===
Amici, ecco finalmente i sorgenti di windows 98:
/*
* TOP SECRET Microsoft(c) Code
* Project: Chicago(tm)
* Projected release-date: Summer 1994
*/
#include "win31.h"
#include "win95.h"
#include "evenmore.h"
#include "oldstuff.h"
#include "billrulz.h"
#define INSTALL = HARD
charmake_prog_look_big[160];
void
main ()
{
while (!CRASHED) {
run_dr_dos_init ();
run_linux_kernel_init ();
run_apple_gui_init ();
display_copyright_message ();
display_bill_rules_message ();
do_nothing_loop ();
if (first_time_installation) {
make_50_megabyte_swapfile ();
do_nothing_loop ();
totally_screw_up_HPFS_file_system ();
search_and_destroy_the_rest_of_OS2 ();
disable_realaudio ();
disable_mozilla ();
disable_misc_competit_code ();
hang_system ();
}
write_something (anything);
display_copyright_message ();
do_nothing_loop ();
do_some_stuff ();
if (still_not_crashed) {
display_copyright_message ();
do_nothing_loop ();
basically_run_windows_3 .1 ();
do_nothing_loop ();
do_nothing_loop ();
}
}
if (detect_cache ())
disable_cache ();
if (fast_cpu ()) {
set_wait_states (lots);
set_mouse (speed, very_slow);
set_mouse (action, jumpy);
set_mouse (reaction, sometimes);
}
/* printf("Welcome to Windows 3.11"); */
/* printf("Welcome to Windows 95"); */
printf ("Welcome to Windows 98");
if (system_ok ())
crash (to_dos_prompt);
else
system_memory = open ("a:swp0001.swp", O_CREATE);
while (something) {
sleep (5);
get_user_input ();
sleep (5);
act_on_user_input ();
sleep (5);
}
create_general_protection_fault ();
}
===
MoonSound Greatest, Volume 1 and 2...
Hello, For people who don't have a MoonSound but still like to listen to the music made with this fabulous piece of MSX-hardware we made a audio-CD with a selection of the best (?) music created with MoonSound. Each CD contains 25 songs and the total playing time is over 73 minutes! The price of this audio-CD is fl.15,- Volume 1: 01 Careless For Strings - Master Of Audio2:34 02 Counterpart - Bart Roymans 3:28 03 Street Fighting- Omega 1:53 04 Be Dust - Nae-Heon Lee 3:30 05 Frozen Destiny - Qix 4:13 06 Chains Of Society - Master Of Audio1:40 07 Away From Home - MadMax 2:01 08 Complete Emptyness- Joan3:16 09 Dike Twin Mike - Bart Roymans3:47 10 Endless Night - Dave Groenen 2:49 11 Fairy-Tale - Qix 2:41 12 Lethal Being- R v.d. Moosdijk 3:29 13 Lucifer - Hans Cnossen 3:12 14 Mayhem Internals- Mayhem 2:44 15 Metalion -Gradius 2- - Hegega 3:30 16 Moving Forward - Qix 1:51 17 Plug Pray - R v.d. Moosdijk 1:40 18 Runner'95 - Dreamscape 4:37 19 Something Got Me... - E. Boon 3:06 20 Search For A Cloud- Bart Roymans 2:11 21 The Profile- Mayhem 4:30 22 Stanacs - Dreamscape 2:38 23 Turrican - Fuzzy Logic 1:46 24 Twilight Heart- Wolf 4:13 25 Si O No - Shan 3:36 Volume 2: 01 100% Intro - Mayhem2:14 02 Civilization - Bart Roymans 3:34 03 Copyright - Dreamscape3:31 04 An Ordered Falling...- Meits 2:35 05 The First Action Move - Qix 2:29 06 Impaccable Endscroll - Dreamscape3:05 07 Llightning - Omega 5:26 08 Destruction II - Master Of Audio 1:10 09 Papua New Guinea...- R Schrijvers 4:47 10 Domina (MSX Remix) - Omega 4:12 11 The Quicksand Valley - Bart Roymans 3:13 12 Mystic Runes - Master Of Audio 1:09 13 Happy Heineken - Meits 2:54 14 Junglerock - R v.d. Moosdijk2:13 15 Golden Star - Qix 2:12 16 Pipelining - Mayhem 1:27 17 Without You - Master Of Audio 1:56 18 Whistles - Bart Roymans 3:29 19 Staff- Dreamscape 3:02 20 Guitarman - Mayhem 1:27 21 Some Memory's- Qix 2:59 22 Prologue IV- R v.d. Moosdijk 3:17 23 Tragedy - Mayhem1:43 24 Centre Sphere - Bart Roymans 3:11 25 The End - Dreamscape 4:26 I'm still looking for music to finish Volume 3... --[ MARI ]-- -- Visit XSW-Magazine's HomePage at: http://www.xsw-msx.demon.nl -- M.H.M. van den Broek Molenweg 17 5342 TA Oss The Netherlands +31 (412) 630653 / +31 (622) 125592 -- MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Breaking the 32Mb/partition limit
At 01:35 PM 1/2/98 +0900, you wrote: Addressable range: 2 Mb = 512 bytes * 2 ^ 12 (FAT12) 32 Mb = 512 bytes * 2 ^ 16 (FAT16) MS-DOS 4.0 (or more) allowed to use FAT16 with an extra feature, the cluster, which is a group of sectors, an do, even if the physical read unit is 512 bytes, the assignements are now made per cluster instead of sectors (I guess everyone knows about that), which is the allocation unit. You are wrong: the cluster feature is available in all the versions of MS-DOS, and of course also MSX-DOS, not only the higher than 4 versions. Indeed cluster have been used since the first DOS release. But for some reason MS-DOS introduced 32Mb partitions in version 4.0. Does anybody know why? But for two (or even three ?) reasons this is now changed using the MS-DOS 7.0"b" from Windows 95b (OSR2 with FAT32): My aspirations is only to read FAT16 disks. I think FAT32 is too big nowadays for MSX users! 8-) I agree, to handle 32 bit cluster numbers a lot more changes are necessary. If we go that far, why stick to FAT at all? There are alternative ways to make file systems, many of which have better performance than FAT. But this is not very useful for nowadays MSX, in my opinion. FAT12: 128 Mb = 512 bytes * 2 ^ 12 * 64 (4 times bigger than actual limitation, still using FAT12 but it needs changes in boot sector for the number of sectors) FAT16: 2048 Mb = 512 bytes * 2 ^ 16 * 64 (about 4 millions sectors, which is the FAT16 limitation even on MS-DOS) Not bad! Imagine 2Gb partitions on your MSX!! Note that using 64 sectors/cluster gives a huge memory demand for your MSX. 64 sectors is 32K, so every cluster in memory eats up 32K of your precious MSX memory. For FAT16 this is not such a big problem, since if you have enough money for a 2Gb harddisk for your MSX, you can probably also afford a 4Mb memory maper. But for FAT12 this is a real problem, since cluster sizes are 16x larger than FAT16 for equal partition sizes. SCSI, IDE, and all the MSX disk controllers uses MSX-DOS (2) for handling the file system. And MSX-DOS (2) is prepared for handle only 12 bit FAT and 16 bit sector numbers. It is only a software problem! Yes, it's only a software problem. But a bigger software problem than you might think. Going from FAT12 to FAT16 can be done by modifying only DOS2. But that alone doesn't break the 32Mb partition limit. You need more bits to specify the sector number. The problem is that the current way of communicating with the hard disk interface is using a CALL that expects the sector number as a 16 bit value. So to allow 32Mb partitions, you need a new way of CALLing the hard disk interface. Hard disk interfaces should then be equipped with a new ROM that implements the new CALLing standard. Besides, maybe MSX-DOS 1 don't allows these modifications. I don't think anyone wants to use a 32Mb partition under DOS1. Imagine 100Mb of files without the ability to create sub directories... If we just leave floppy formats as they are, DOS1 users should have no problems. The existing direct sextor access functions of DOS should remain usable, but limited to the range 0-65535. New functions for the extended range should be added then. This is what I mentioned a few paragraphs ago. Note that this change will only work when hard disk inferface ROMs are changed as well. * the way of reading the FAT itself Yes, this is the main problem. Is for this that I request for information about the DOS 2 internals! Hard disk interfaces exist that have DOS2 internally. Maybe the manufacturers of those interfaces have a source code of DOS2? * all the other changes related to the total number of sectors as with the FAT12 + big clusters method) It is easy: the total sectors number must be read from #20-#23 if the data in #12-#14 is zero. Investigating the possibility of adopting the MS-DOS "BIGDOS" partitions is a good idea, in my opinion: - We are solving the same problem MicroSoft did several years ago. I'm not saying MicroSoft chose the best solution, but we can learn from their design decisions. - Compatibility between MSX and PC hard disk partitions is a good thing. I'm very happy with the floppy compatibility, and hard disk compatibility is simply the next step. Think about ZIP disks for example: it's very practical if you can exchange those between PC and MSX. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX Mouse ?
Valery wrote: Hi all, Who know information about MSX mouse intreface and protocol (time diagramm )? Valery Hi, I don't know exact timing, but I can tell about how to access. It is done through PSG, registers 14 and 15. Just in case you don't know: PSG is written to in the following way: Don't ever use this method for register 14! It is said to kill you PSG! LD A,register_number OUT (HA0),A LD A,data OUT (HA1),A For register 14, it should be: LD A,14 OUT (HA0),A IN A,(HA2) As you can see, PSG 0-13 and 15 are write only, while 14 is read only. Register 14 has the following form: Bit Function 0 up 1 down 2 left 3 right 4 button A 5 button B 6 I don't remember 7 cassette input bit 0-5 refer to the joystick selected by register 15, bit 6 Register 15: Bit Function 0 button A joystick port 1 1 button B joystick port 1 2 button A joystick port 2 3 button B joystick port 2 4 strobe joystick port 1 5 strobe joystick port 2 6 joystick select (0=port 1, 1=port 2) 7 kana-led (at least that is what I was told, I don't have a japanese MSX myself, so I couldn't test it) I'm not sure if I mixed up bit 1 and 2... Anyway, when using this keep the following in mind: R15, bit 0-5 are used to put 0 or let-go-high on the pins. If you push a button on the joystick, it will connect the pin to earth (0). By reading the stick (through R14), it checks the voltage on the pin. If it is high, it returns 1, if it is earth, it returns 0. This means that if you write 0 to R15, bit 0-3, and than read the button status, it will always be low (forced by the computer itself), so it will return low as well (code for pressed button). You have to watch out with that. Even worse: The joysicks I have at home (arcade they are called, not official MSX, but they work good) have their switches connected to strobe in stead of earth. This means that if you set the strobe bit to 1 and than try to read the stick (buttons or direction), it will always return 1 (except if they are forced to 0 by writing 0 in bit 0-3, in that case it will always be 0). So even when reading joystick, don't play with the strobe bit... Now why do I tell this, when you ask about reading the mouse? Because the MSX-computer uses what is called a joystick-mouse. It is read out as a joystick. The mouse returns the displacement from last read-out, not the position or something like that. If 2 programs both read out the mouse, 1 of them probably doesn't work, because the same data is not output twice. Anyway, how to read it? It is easy. There is 16 bit output (one byte for each direction) and it is read as follows: set strobe to 1 wait k clockpulses read data xl set strobe to 0 wait n clockpulses read data xh set strobe to 1 wait n clockpulses read data yl set strobe to 0 wait n clockpulses read data yh This makes clear why sometimes you have to unplug a mouse from the computer and than plug it in again. The mouse cannot see if you are asking for x or y data, so if it gets mixed up once, it will stay that way. By the way, MSX mouse does, of course connect the pins to earth. So don't worry about reading it with strobe high. The data is read from R14. Bit 0-3 are the wanted data, bit 4+5 are button-status, as usual. Other people might have wanted to know this, but I think this is not the answer to your question. I think this, because you ask for a time diagramm. That means you want to know the minimum values of k and n. I'm sorry, those values I don't know. I have seen programs with the following wait-loop: LD B,xx LABEL: NOP DJNZ LABEL for k, xx was taken 40 and for n 20, but this is probably not minimum. Therefore, I also want to ask the question: What are the minimum values? By the way: using minimum values might of course give problems to 7MHz (Ok Alwin, it's not 7, it's 3.59*2=7.2Mhz) MSX's and TR's. Since I don't have any of them, I don't know if there is a built in hardware solution for such problems, but if not, it would be advisible to make it a bit slower. Of course TR _can_ run on it's Z80, but the users will not like to do this just to make the mouse work a fraction faster on other MSX's. Still, it is the choice of the programmer. If you make it working fast on a 'normal' MSX, it is standard. So everything that doesn't work than, is not a MSX... But of course, this is not a very nice way to look at it. Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Smaller...
Hi! | A|A (n n) \_/ I hope this EM gets smaller than the previous one about segmentation. I'm here, again, to comment several EMs at once. First subject: Robotz. I implemented a game in BASIC in last December. I'm not kidding, I have a witness! A friend of mine saw it working (three robots battled till only one last - of course, there can be only one!) Yes, the program still exists, but it is a mess and don't fit the specifications (hey, give me a break, I implemented it in one week, with no specs at all, only ideas, just to keep some ghosts of mine away...) The program didn't send data through a network, but there was a protocol for communication that simulated it (I made "fair" robots, of course, what would be the use of I cheating myself...?) Thus, I could test different robots in a single MSX, as if they were spread in a network. But after reading the docs (0.2 and 0.3 - got this ahead, looking into the latest EMs in my box), wow! Sorry, it's too complicate and I don't have the time. I'm already engaged into a JavaScript adventure and won't be able to implement it (the BASIC program did take me a lot of time, what to say about that!) Yes, it seems to be a very powerful robot programming language, but I'm not at all sure it can be done... I'll read it more carefully at home, getting drunk with grape juice, lustfully eating chocolate cookies... Okay, next: compression, the smaller is better! Do you know A.C.T.? It stands for "Archieve Comparision Test". It can be found at "http://act.by.net". If you, like me, thought RAR was powerful, you haven't seen 777, UFA, RKive, IMP, BOA Constrictor and others. Unfortunately, some of them are meant to be only for PC (worst, for Win95 - they use that stupid long-name structure). Among the others that run in MS-DOS, some require more than 32MB of RAM to start! Well, but this is supposed to be about MSX, and it is! The better the compression rate, more memory the archiving program will require (there is a wider range of combinations to test). About speed, well, that's another story. Taking a quick look at A.C.T., it's possible to notice that some programs are really fast when not trying maximum compression, and even so can reach really amazing rates. Oh, yes, some of that programs are free and have the sources available. The problem with MSX is that it is a small "niche". How many PC users would be able to handle PMA files? How many types of files can be read and manipulated in PC and in MSX? Yes, the proportion of scaring. MSX can read, let me see, about five types (LHA/LZH, ZIP [seems to be troublesome], PMA, ARJ and softhouse custom packers). Well, check A.C.T. and try to count the number of different packers available (it is explicited nowhere in the Page, but it is for _PC_ compressors). Of course, if you take the problem to other systems, you go crazy (have any of you stumbled into a packer named "stuffit", for Mac?) or is completely ignored (how would a common Mac user read a PMA file?) I think the easier solution is to adopt one packer, one accepted by as many systems as possible (LHA, Zip, Arj, RAR etc.) I don't like to admit it, but Zip is the most widespread (I use Info-ZIP freeware, not the PKWare original). A good MSX port of it would be nice, but it requires a lot of C libraries (I'm not sure MSX can deal with it). It is good to have all that in mind before starting to design a new and incompatible compressor for MSX (I once made one in BASIC, using pure Huffman - it took half an hour to compress a 16KB file...!) Anime trivia: when I was in Japan in the beginning of 1997, a new Ghibli "anime" was arriving the local theaters: "Mononoke Hime" (Princess Mononoke). Only last week, two years later, I could watch it. Wonderful! If you have the chance to see it, do it now! The same producers of "Nausicaa", "Tonari no Totoro" and "The Last Unicorn" (my forever favourite movie...) ... Cyberknight... Over MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: New joystick communication standard proposal
At 06:11 AM 8/17/98 -0700, Werner Augusto Roder Kai wrote: - Maarten found the solution. Using only one port we can connect several MSX computers, keeping another port free to use the joystick (for a game) or the mouse (for an application). And for two computers, the cable keeps the compatibility with F-16 and F1Spirit 3D cables. Actually that was not my idea. But it's a good idea anyway. - Is NOT good to standartise that the cable will be always in port 1 or port 2. If you have a MSX with problems in the specified port, you won't be able to connect it... I agree. - So, The port can be 1 or 2, and the new softs MUST detect in which port is the cable, though F-16 and F1Spirit3d need the cable in port 2. Someone (Laurens?) remarked that hardware autodetect is not such a good idea. A protocol which can detect the cable as part of the initialisation is easier and more flexible. - DIN-8 has too much pins and is hard to obtain in some places. The DIN-5 connector is enough for us and more easy to find. DIN5 was chosen for the final standard. SEND/OUT (DIN-5 male) RECV/IN (DIN-5 female) NC 5 5 NC out0 4 ---+ +-- 4 in0 out1 3 -+ | | + 3 in1 in2 1 -+ | | | | +-- 1 out2 gnd 2 --+--|---|-|--|-|-|--++-- 2 gnd | | | | | | | || ext -+ | | | | | | |+- ext | +-+ | | | | | | | | | | | | | | | | | | | | | 3 4 7 6 1 2 8 9 On the mailinglist, we agreed on using a different connection scheme for DIN5: 1: data0 (D0) 2: data1 (D1) 3: data2 (ACK) 4: NC 5: gnd shielding: gnd A long cable is used for sending (MSX pin 6,7,3) and has a male DIN5 plug. A short cable is used for receiving (MSX pin 1,2,8) and has a female DIN5 plug. We think is not important to standartise pin usage or software. Software is not important to standardize. But it can be usefull to distribute a sample/default protocol so that software developers can create software with less effort. Pin usage is important, because ACK (data3) is connected to a different computer as data0 and data1. The names "data0" (D0) and "data1" (D1) are very general, so you can always decide the actual use for yourself. The maximum transfer speed is theoretically only limited by the MSX clock but the cable impedance (lenght and the existence or not of shielding) may decrease the rate. So the standard should also include "you must use shielding" and "maximum cable length is xx meters"? We should make a official homepage to spread the new standard, with instructions and examples about how to make the communication and some basic routines (but not standard routines). I made a page: http://www.stack.nl/~mth/msx/hardware/ Laurens also made a page. I don't mind who will make the official page. I volunteer. Any other volunteers? The MSX clubs shoud prepair some kits to show and sell in the next MSX fairs with some soft. The start is always hard, but the sky is the limit. I hope a little demonstration can be given at the Zandvoort fair (second half of september). We would like to thanx Sean Young for the information about F1Spirit3D, Laurens and Maarten for their ideas and work in way to make the new standard possible. Also Patrick Lina, Jeroen Smael, Alex Wulms and some other people participated. Yesterday (16/08/98) we made three new cables just like above and re-programmed our game to work with the new pinout. Tomorrow the game in BASIC and the whole source code in Z80 assembly will be in my Homepage to download, and then you will have something more funny to test your cables. Great! Sander Kooijmans is willing to give the sources of Triplex (multiplayer Tetris clone using Music Module MIDI). It should be easy to modify it for the joystick network. The problem is that he's not sure he has the sources on disk. He does have printed sources, so maybe they have to be typed in from paper. Or I can test if OCR (Optical Character Recognision) software really works... By the way, according to my WWW statistics, about 6 people downloaded the cable tester this weekend. Reactions (positive or negative) are welcome at [EMAIL PROTECTED] Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: DOS 1/2 support (was: Split v1.1)
Hi all, (To Laurens: thanks for your nice comment on my pages). Quickly after my previous upload, I again uploaded a utility I wrote once. It's called "Split" (v1.1), (..) Only 'shortcoming': it needs MSX-DOS 2. Laurens Holst [EMAIL PROTECTED] replied: Dos2 RULEZ!!! I was wondering... is there still anybody who hasn't got Dos2??? If not, then I could just make utilities Dos2-only... Lot easier than inluding (terrible) Dos1-support... Oh, I was also wondering who hasn't got a harddisk? Ok, I know the MSX-ers on this list are only the real die-hards, so this will not be a relyable question for the general MSX-user, but still... I'd like to know. Yes, I agee, but: Not supporting DOS 1 is simply a LIMITATION, and I don't like limitations... For instance, something that only supports DOS2, can not, or very difficult be used with emulators, and when you're writing something for MSX these days, I think you should do it so, that it will also work on emulators, or at least don't go to great lengths to PREVENT it from doing so.8-( (Same thing on PC's: although writing for DOS, it's unbelievable how much trouble programmers go through to prevent something from working under Windows 9x-DOS or in a DOS-box...) In these days, I think there will also be many people who might only occasionally use their MSX, and for that purpose have only a 'standard' MSX (probably MSX2), often without DOS2 built-in. If something needs DOS2, that would require having this built in, extra plugging in a cartridge or HDD interface with DOS2, etc., which is just more trouble. If something also supports DOS1 as well, you can just work with what you've got, rather than with what the programmer would like you to have. ;-) In general, I think you should support all things that are not TOO difficult to support, that are not too rare. Only exception would be if the program is for a very special purpose, or if it would mean a really big amount of extra work. For instance, if you're writing a music program to get the best possible out of MSX-Music, you should not only support a particular FM-PAC, but also the -PAK, Korean or other versions, because people might have these, and they all work about the same. Also supporting MSX Audio for this program could mean re-writing the entire program, so it would be understandable to drop support for that. But when you're writing an entire music program, disk functions will only be a small part of it. So her you SHOULD support both DOS1 and DOS2, or at least write it so, that it will also work under DOS2, using DOS1-compatible functions. That's the general idea... For a disk-utillity like this "Split" I made, a large part of the work is command-line parsing, and converting results in disk functions. If I would have wanted DOS1-support for this, I would have had to make a huge part of it disk-version dependant. I might as well have written a separate DOS1- and DOS2-version in that case. So for this, I decided to drop DOS1 support, and make full use of DOS2. If I had to include DOS1 disk functions as well, I might not have done it all (a lot more work). Speaking of DOS2: Strict requirements for DOS2 are a memory mapper, and some kind of disk-drive to work with. Maybe it will even work with only the built-in RAMdisk, without even any real drive attached. Does anyone know if this is true? But what I asked myself some time ago: Would DOS2 work on a MSX-1 as well? Think of it: as far as I know, it doesn't use any SPECIFIC MSX-2 features, only things that are commonly found on MSX-2's, like the memory mapper. But MSX-1's and memory mappers don't byte each other, nor do MSX-1's and harddisks or so. So suppose you have a MSX-1 with sufficient cartridge-slots, and you would plug in a memory mapper, DOS2 cartridge, and disk-interface. After initialising the mapper by hand, and resetting the machine once more, would things work as normal, with Disk BASIC 2.x to go with it? Can anyone try this, just to satisfy our curiosity? (P.S. The combination MSX-1/mapper DOES work as normal, I know this for a fact. You can even run some MegaROM cracks on such a system, that are stating to be MSX-2 only...) Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msx MSX Tech Doc page MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Robotz
Hi!
About the robotz.txt v0.0 file:
2.2 Status Registers
The registers are divided into two classes: public and private.
The private registers can only be accessed by the robot itself, the public
registers are accessible to all other robots
Also mention that they are _status_ registers and as such cannot be
written, only read.
The env register array contains info on the direct environment of the robot.
This register array always reflects the current situation. The robot itself
is placed at env[2][2]; env[0][0], env[0][4], env[4][0] and env[4][4] will
always contain blank data.
Hard-wireing the robot location to (2,2) is not flexible. If you would
allow negative indices, you could place the robot at (0,0) and expand the
scanner range with a lot less problems.
env[0..4][0..4] - the environment
You could also use a part of the memory for this task. That would simplify
the virtual machine.
-
2. Command Set
-
This should be chapter 3! (look in the table of contents).
2.1. Terminology, definitions and abbreviations
byte (un)signed byte value
word (un)signed word value
address word in range $ - $3FFF (15 bit)
flag Z, P, N, NZ, NP, NN (bitmask over flags status reg)
This paragraph is totally out of place (par 2.1 exists three times!). I
think you should put it more to the beginning of the document, certainly
before the terms "byte" and "word" are mentioned.
Note that "word" does not always mean 16-bits (for example PSX uses 32-bits
words). Please mention the range explicitly.
You didn't include a "bit" type in your list of data types (but you use it
quite often in the document).
Actually, I would prefer a "boolean" type to a "bit" type.
I'd like a 16-bit signed type as well ("integer" or "int").
When the robot
gets its turn again, the env registers are updated and the processing
of the program continues at the next command.
Is the stack automatically cleared every turn?
I think that would be a good thing.
SCAN byte
SCAN (address)
MOVE byte
MOVE (address)
...
Why two variants of every action command? Isn't it easier to use the byte
at the top of the stack?
And what does the byte mean anyway?
2.2. Program flow control
These commands influence the program control flow. Their intention
is clear (I think) to anyone with a basic understanding of z80 ML...
JP address
JP flag,address
JP flag,address
CALL address
CALL flag,address
RET
RET flag
How about this construction:
Syntax:
SKIP flag
Semantics:
Skips the execution of the next instruction if the flag is TRUE.
Example:
SKIP Z
JP address
is equivalent to
JP NZ,address
This would make your instruction set smaller and the virtual machine easier
to implement.
Does CALL store an address on top of the stack, or is the stack only used
for arithmetic?
If the stack is used for return addresses, it would be very difficult to
pass parameters to a subroutine. Please think about this!
2.3. Stack operations
The machine uses a stack for calculations. It's a stack of words,
not bytes.
PUSB byte (but stores a word to keep stack handling simple)
PUSH word push word on stack
I think you should specify how PUSB stores the byte in a word. People are
bound to use this, so you'd better standardize it.
PUSH (address) push word at address address on stack
Why doesn't PUSB (address) exist?
CLR clear the stack (dangerous! :-))
Why is this instruction needed?
2.4. Arithmatic operations
The arithmatic operations take the two topmost elements of the stack (or
only the stack top, for NEG), perform the operation and push the result
on the stack again. Flags will be set as expected.
"As expected" is not good enough: different people will expect different
things.
ADD
SUB
MUL
DIV
Please include "MOD" as well.
And define it such that "-1 MOD 3 = 2", not "-1 MOD 3 = 1" like Pascal.
NEG
What is the meaning of NEG when there are only unsigned types?
(include int!)
2.5 Logic operations
AND
OR
XOR
NOT
Are these only defined for booleans, or are bitwise operations on words
supported as well?
2.6 Assignment
Unlike the z80, this machine has no general purpose registers, so 4 load
instructions should suffice.
Actually, you don't need load instructions at all. Using the PUSH and POP
operations, you can do anything a load instruction can do.
Maybe some of you think "such a simplified virtual machine is not easy to
program". That's true. But it's very easy to interpret, and it's also easy
to make a compiler that compiles to such a virtual machine. So you don't
have to program in the virtual machine language, but you can use a higher
level language instead.
Keep up the good work! (please make v0.1 soon)
By the way, anyone interested in virtual machine design should read the
"Java virtual machine specification"
Re: Bigger sector numbers
At 05:15 PM 11/26/98 +, you wrote: But you still haven't convinced me (and some others) why 4010 should be updated instead of creating a new routine at a new address. The issue here comes down to: Why have programmers learn the use of a new call, By changing parameters of an existing call, like you suggested, programmers have to learn the changes as well. This is unavoidable. make every single piece of software that PERHAPS might still have some use, useless 'by definition', I can't think of any software, written for 16 bit sector numbers, that will function well on a partition requiring 32 bit sector numbers. My view on this is simple: define new methods/entries etc., when there is a CLEAR ADVANTAGE to be had from this. If no such clear advantage exists, use existing entries/methods if possible, this will simply minimize the overall impact, and make acceptance easier. Advantages: - HD BIOS implementation doesn't have to check whether old (16-bit) or new (32-bit) calling convention is used. - Complete freedom in specifying parameters. a) Doesn't your harddisk-interface allow you to simply disable a partition? If yes, do so, and you've got no problem here. If no, I suggest you get that fixed first. If you know you are going to run a program that can mess up your 32MB partitions, this works (although clumsy). But the most harmful accidents are the ones you don't expect. b) I have never liked it, that having a HD interface, in most cases meant that floppy drive letters A B moved to F G or whatever, and changed again when removing or adding partitions. Instead, I would much more prefer the PC method here, to give floppy drives fixed letters A B (who's got floppy drive C or D anyway?), and start harddisk partitions with C, D, etc. Doing so would fix many of these old program's problems as well. It fixes problems with programs messing up HDs because they think it are floppies. It doesn't fix problems with 16-bit sector number programs messing up 32-bit sector number partitions. But there was a different suggestion that will work well to protect partitions: direct sector I/O must be enabled explicitly by the user. For example, by specifying a certain environment variable. It's not easy for the programmers of the HD BIOS. To fetch the sector number, the memory it is in must be selected. But by the time the HD BIOS looks up the sector number, a lot of slot switches have occured. Reading the correct values would take an inter-slot-read, which is slow. If called by a user program, all user memory will be selected when the driver ROM is called, except in page 1. If you are programming under DOS, your code and data is located in page 0, 1, 2 and maybe even 3. How can you be sure that your sector number isn't stored in page 1? You can assign an address explicitly (using EQU), but that is not a flexible way of programming. If the BIOS routine is called, the system can copy the value to a save location in page 3 or elsewhere in case it was in page 1, or leave it alone otherwise. But where is "a safe location in page 3"? If you can find one, you might as well let the user store the sector number there. Calling driver entry 4010h directly from an application program would be illegal (as it is now, strictly speaking), with the parameters in any other than page 1, no problem anyway. Loading sectors to page 1 is perfectly possible in DOS1 and DOS2, as far as I know. For the BIOS/diskROM entries, it would pose a problem to define new entries; where to place such a new entry? #4034 and beyond, plenty of space left. Available, but would require the data/software there to be moved elsewhere, and every routine calling/using the data on this address to be adjusted. That's the real problem with this, simply a lot of work, that might be avoided. Yes, it is true that patching DOS2 will be more difficult. If called with A=2 (get info on FAT16 support): returns: A=0: no FAT16 support A0: FAT16 supported Any extra info to be determined later, if necessary More useful would be a call that tells you which filesystem is used on a particular drive. Imagine a system with both a FAT12 and a FAT16 partition active. Knowing that FAT16 is supported is not enough, you have to know on which drives. To make this more general: you want to ask which filesystem is used on a certain drive. That's another matter: what filesystem is used on a particular drive, is depending on the medium/disk in that drive, not on the system that handles it. What I mean is, that the average program doesn't care whether FAT16 is supported, it only matters whether it is or isn't used on a certain drive. I think only FDISK and FORMAT need to know whether FAT16 is supported. Your remark about "depending on the medium/disk in that drive" is a good one, I forgot about removable media. For example ZIP disks, it would be useful to partition them with a single partition. Bye,
Re[2]: Robotz
Hi!
Hard-wireing the robot location to (2,2) is not flexible. If you would allow
negative indices, you could place the robot at (0,0) and expand the scanner
range with a lot less problems.
Placing the robot at (2,2) was indeed an attempt to avoid negative indices.
Putting the robot back to (0,0) is not much of a problem :-)
env[0..4][0..4] - the environment
You could also use a part of the memory for this task. That would simplify
the virtual machine.
The problem I had with putting the environment in memory, was that you
end up with two types of 'status': the status registers at one hand and
the environment in memory at the other hand. With the env in registers,
the complete robot machine state is in register and independent of the
memory. Also, there's less possibility of overwriting the env by accident
in this way...
I'd like a 16-bit signed type as well ("integer" or "int").
Maybe my notation was a bit unclear (hey, it was a very first preliminary
pre-alpha 0.0 version!! ;-)), but with (un)signed I meant that both signed
and unsigned types exist.
Is the stack automatically cleared every turn?
I think that would be a good thing.
No! The stack must remain intact! A program could e.g. have a function
(subroutine) that performs a few scans (cost a turn each!) and then
give as result (on the stack!) the direction in which the robot should go.
Why two variants of every action command? Isn't it easier to use the byte
at the top of the stack?
Hm, come to think of it. Not a bad idea at all. As I said before:
Let's keep it simple! :-)
And what does the byte mean anyway?
Ehm... in case of SCAN; the direction in which should be scanned, in case
of MOVE and ATCK the direction in which should be moved/attacked.
Syntax:
SKIP flag
Semantics:
Skips the execution of the next instruction if the flag is TRUE.
Example:
SKIP Z
JP address
is equivalent to
JP NZ,address
Perfect!
Does CALL store an address on top of the stack, or is the stack only used
for arithmetic? If the stack is used for return addresses, it would be very
difficult to pass parameters to a subroutine. Please think about this!
I was thinking of using another, machine internal, stack for return addresses
with exactly the possibility to pass parameters on the stack. Maybe I could
include a mechanism to perform indexed access to the stack, to make accessing
parameters easier. (I really have to dig up my lecture notes on compilers
again :-))
I think you should specify how PUSB stores the byte in a word. People are
bound to use this, so you'd better standardize it.
The idea was to store the byte in the LSB of the word (of course :-))
PUSH (address) push word at address address on stack
Why doesn't PUSB (address) exist?
Ehh... because I forgot to put it in :-)
CLR clear the stack (dangerous! :-))
Why is this instruction needed?
I don't know if it is needed. Actually, I think I'd better leave it out...
Please include "MOD" as well.
And define it such that "-1 MOD 3 = 2", not "-1 MOD 3 = 1" like Pascal.
Ok.
[logical ops]
Are these only defined for booleans, or are bitwise operations on words
supported as well?
I haven't thought about that, yet. I personally don't use the bitwise
operations a lot, but I guess they could come in handy, at some time...
Actually, you don't need load instructions at all. Using the PUSH and POP
operations, you can do anything a load instruction can do.
True. I'll get rid of them in the next version.
Maybe some of you think "such a simplified virtual machine is not easy to
program". That's true. But it's very easy to interpret, and it's also easy
to make a compiler that compiles to such a virtual machine. So you don't
have to program in the virtual machine language, but you can use a higher
level language instead.
That was exactly what I had in mind :-)
Keep up the good work! (please make v0.1 soon)
Thanks. I will! Most of the unclarity in the 0.0 version was to my eager
to give it out to the people. Besides, it's easier to embed comments (and
extract faults and other bugs!) in earlier stages of development...
Eric
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Yamaha FM Synthesizer chips...
Greetings NYYRIKKI, NY I was looking information about Yamaha FM-Sound Synthetsizer Unit II (SFG-05) that was included also to Yamaha CX5M MSX My Yamaha CX5M was given to me, years ago, by a friend who worked in the service department of a music store. But, it doesn't have the FM Synthesizer cartridge (I guess that's why I got the CX5M for free), otherwise I'd send you a binary image of the FM EPROM. I have the CX5M Service Manual. Here's everything that it says about the four Yamaha chips (OPM, DAC, ROM, and MKS) ... 1) OPM (YM2151): FM sound synthesizer of the FM sound synthesizer unit. When used with a D/A converter (DAC), 8 audio tone signals can be obtained at the R and L channels. The YM2151 has 8 note capability and it is also equipped with a noise generator, vibrato oscillator, amplitude modulation circuit, tonal effect generator and timer circuitry. 2 sets of times are used and when a timer overflows an interrupt request takes place. 2) DAC (YM3012): As related to the OPM section, this is a D/A converter tp produce 2 channel (left and right) audio signal. 3) ROM (YM2270-2): Program is written to control MKS and OPM and located in Slot #3 000H..z3F7FH. 4) MKS (YM2148): MKS has a MIDI function, keyboard scan function and supports MODE 2 IRQ for CPU. MIDI is a synchronous serial data transfer of 32.25k baud transfer rate. Keyboard scan is a function to handle keyboard ON/OFF data of the connected music keyboard. When MODE 2 IRQ takes place, due to demand by CPU, VECTOR ADDRESS goes out to DATA BUS. (To view the following table, use a fixed-width font...) == FM Sound Synthesizer Unit Address Map: ==+===++== Addr | Inputs | Output | Internal Registers | /CS RD /WR A2 A1 A0 | OPM | --+---++-- | 1 - - - - - | 1| - | - - - - - - | 1| - | - 1 1 - - - | 1| - --+---++-- 3FF0H | 0 0 1 0 0 0 | 0| OPM Status Register | 0 1 0 0 0 0 | 0| OPM Address Reg --+---++-- 3FF1H | 0 0 1 0 0 1 | 0| OPM Data Reg | 0 1 0 0 0 0 | 0| OPM Data Reg ==+===++== 3FF2H | 0 1 0 0 1 0 | 1| ST0-ST7 Output Data | 0 0 1 0 1 0 | 1| SD0-SD7 Input Data --+---++-- 3FF3H | 0 1 0 0 1 1 | 1| MIDI IRQ Vector Addr | - 0 1 0 1 1 | 1| - --+---++-- 3FF4H | 0 1 0 1 0 0 | 1| External IRQ Vect Addr | - 0 1 1 0 0 | 1| - --+---++-- 3FF5H | 0 0 1 1 0 1 | 1| MIDI UART Data Read Buff | 0 1 0 1 0 1 | 1| MIDI UART Data Write Buff --+---++-- 3FF6H | 0 0 1 1 1 0 | 1| MIDI UART Status Reg | 0 1 0 1 1 0 | 1| MIDI UART Command Reg --+---++-- 3FF7H | - - - 1 1 1 | 1| - ==+===++== Here are the Yamaha part-numbers for the above chips (you might be able to order the ROM chip) ... YM2151 OPM (IC101): #IT-21-51-00 YM3012 DAC (IC102): #IT-30-12-00 YM2148 MKS (IC103): #IT-21-46-00 YM22702 ROM (IC104): #IT-22-70-20 You can download the OPM and DAC User Manuals from... ftp://ftp.yamahayst.com/pub/Fax_Back_Doc/Sound/YM2151.PDF ftp://ftp.yamahayst.com/pub/Fax_Back_Doc/Sound/YM3012.PDF Also check out http://www.yamahayst.com Apparently, these chips are also used in some Sega games. I saw some YM2151 information at... http://www4.ncsu.edu/~nscorlet/ym2151/ Cheers, Greg_ http://www.netcom.ca/~telic 1998.Oct.16, Toronto, Canada MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: speeding up interrupts
Hi, About stopping the diskdrive after disk actions: This particular address mentioned earlier contains a drive-off counter. It is set to, I think, 254, after every disk action, and decreased 1 on every call to the diskROM's interrupt handler (so every timing-interrupt). If it reaches zero (so after some 5 seconds), the drive motor is stopped. If THIS drive is accessed again in the meanwhile, the interval starts again. The value 255 has a special meaning: 'keep running'. If you do something with the drive, and POKE 255 in this memory location quickly (before the counter reaches zero), this diskdrive motor simply keeps running. The address is simply the same on many MSX machines, because they use similar working diskROM(s), but it is NOT a fixed address in any way, not documented, not guaranteed or such, in one word: don't rely on something like this, if you do, someone will have troubles because of it, some other time. I figured out this approach to stopping disk drive motor(s, note there might still be another drive running, if you start this game quickly enough from a different one): LD IX,#4029 LD IY,(#F347) CALL #001C This is a call to a diskROM entry, which (should) contain a routine that 'scans' all diskROMs, and calls another entry in each, which should be present in each diskROM, to stop the drive. The address F348h contains the slot-address of the 'main' diskROM (the first one, that handles the initialising stuff and so on), the address 4029h is one of a small number of entries present in any diskROM, and are described in the MSX Technical Databook (I'm not sure if they're also in the MSX2 Tech Handbook). You can call the method above pretty solid, and it should work whenever there IS a diskdrive (contents of FFA7hC9h). But: on using this myself, I found these drawbacks: -It stops DRIVE-motors, doesn't do anything with other interrupt-related processes that might be running. -On my Novaxis SCSI, it stopped the HDD motor as well (great, mine made a lot of noise). But those stupids from Gouda did implement this diskROM-entry, but forgot to turn on the drive again when accessed, in case it was shut down this way (! stupid, stupid...) So, shutdown the drives this way, and you'd have to reset the machine again, just to get the HDD spinning again (I switched it on and off instead). -This diskROM-entry might not be (properly, or not at all) implemented with a particular disk system I would say calling the hook at FD9Fh 256 times (do yourself a favor, no less than 256..), is by far the best, AND most compatible/problem-free way of shutting down disk-drives and such. I'd say this IM2 approach is not a bad idea (and yes, there need to be 257 of the same values on the address I*256), it prevents you from HAVING to switch RAM in page 0, and you can select a different starting address for your interrupt routine, which is called immediately on each interrupt, rather than having to wait for a few instructions at #0038 to get executed first, before a hook-address is called. If you'd switch RAM in page 0, you'd also have to setup at least the slotswitching-routines, which are the same under DOS, BASIC, and even present in MSX-2 subROM. I'd say, a lot of work. Best way would be to use this IM2-approach during run-time, using all 'common' hardware (VDP, keyboard etc.) by direct I/O (remember any BIOS call might re-enable interrupts, and mess up things when you'd expect these to be off at that time), and temporarily switching back to IM1, and restoring memory settings etc. when making any BIOS or disk CALLs. Your program might have a setup like this: On startup: -Store any memory settings, in case you need to change, and restore these later (other initialisation) -Set up your interrupt handler -Set up this 257 byte table (interrupt handler at address 257*fillbyte), starting at a 256-byte boundary (low byte 0) -Set Z80 I-register to the high byte of the address of this table -switch to IM 2 -enter a main loop of your program On a disk-access/BIOS-call: -restore memory settings, if needed, possibly update some system memory locations containing VDP-register contents and so forth -switch back to IM 1 -make your BIOS/disk CALL -(.. make some more disk CALLs) -call FD9Fh 256 times -switch to IM 2 again On exit: -Do the same restoring as before -Switch back to IM 1 If that still doesn't do it: -Use a faster METHOD of obtaining your goal -Write even faster code -make a turbo-circuit (6/7 MHz. or my own) a system requirement -or make it a TurboR program Greetings, Alwin Henseler([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msx(MSX Tech Doc page) http://www.twente.nl/~cce/index.htm(Computerclub Enschede) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED]
Re: Yamaha FM Synthesizer chips...
"Greg_" ??? You !?!? Oh, you don't know how much I would like to kill my self right now !!! I have been looking this information all over the world, and I have even tryed to contact Yamaha in USA without any help. Kari Lammassaari (ACADEMY) has been looking this information too about 10 years, and then you appear to be in this mailing list with us and with all this information ! I could have asked this question here long time ago, but I just didn't belive, that anybody has this information here, just this close. AARGH Thank you, thank you, thank you, thank you, thank you !!! You have just helped us a great step forward, finaly I can get some real cool sounds out of my MSX tR !!! I think, that this is much better music expansion, than some MSX-MUSIC or MSX-AUDIO. Maybe I can make some own music editor or FM-Pac emulator or MBM replayer or... Ok, I try to calm down... Because rest of you don't even know where this all started, then here is the original message : I was looking information about Yamaha FM-Sound Synthetsizer Unit II (SFG-05) that was included also to Yamaha CX5M MSX computer and I founded out, that you can maybe help me. I have done some research, and I have allready founded out how to read keyboard (YK-01 or YK-10), but I still don't know how to produse a sound with this DX7 compatibble FM-Chip. So, I would be wery grateful, if you could give any information about this FM-BIOS or addresses #3FF0-#3FF6, that controlls I/O of this module. My Yamaha CX5M was given to me, years ago, by a friend who worked in the service department of a music store. But, it doesn't have the FM Synthesizer cartridge (I guess that's why I got the CX5M for free), otherwise I'd send you a binary image of the FM EPROM. This is no brobblem. I have this device allready, and I have monitored this ROM quite a much. Anyway I have not getted any sense about it. (Too much CALL commands jumping around etc.) :-( BTW I have founded a small bug from the FM-BIOS, that makes life easy for Panasonic MSX tR and MSX 2+ users. As you have maybe notised, both modules, this and FM-PAC uses CALL MUSIC command. When you type CALL MUSIC in these computers, FM-PAC handles this command, and it newer goes to this sound unit. Anyway, if you type forexample CALL MUSICA then FM-PAC will not regognize it as a command, and it will pass it trough to next device. This FM-BIOS does not check this last letter at all, and the proggram will start ! 1) OPM (YM2151): FM sound synthesizer of the FM sound synthesizer Name of this chip is very important, for finding information. I did not have even this ! --+---++-- 3FF0H | 0 0 1 0 0 0 | 0| OPM Status Register | 0 1 0 0 0 0 | 0| OPM Address Reg --+---++-- 3FF1H | 0 0 1 0 0 1 | 0| OPM Data Reg | 0 1 0 0 0 0 | 0| OPM Data Reg I guessed these ones right, and I managet even to get some noice, but without any reasonabble method. :-) ==+===++== 3FF2H | 0 1 0 0 1 0 | 1| ST0-ST7 Output Data | 0 0 1 0 1 0 | 1| SD0-SD7 Input Data Yeah, this is very clear to me. If someone want's sources, I can send them. Maybe they will be added to my www-page too in the future. I'll try to do whole proggramming manual for this module, as soon as I have enough time to get some sense about it. You can download the OPM and DAC User Manuals from... ftp://ftp.yamahayst.com/pub/Fax_Back_Doc/Sound/YM2151.PDF ftp://ftp.yamahayst.com/pub/Fax_Back_Doc/Sound/YM3012.PDF Great ! I just can't view these .PDF files :-( Maybe I can go to look them to my friend soon. Apparently, these chips are also used in some Sega games. I saw some YM2151 information at... http://www4.ncsu.edu/~nscorlet/ym2151/ Pictures again :-( Well, anyway I'll download them just after sending this message. Greetings : ,_. _=_=_=_=!_MSX_!=_=_=_=_=_=_=_=_, ! A1ST ~--- - I ( o o o o o o )i /`, / .::;::; ., / :::.:.:.::::!. -=- `, ~== NYYRIKKI : [EMAIL PROTECTED] MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
Hi, As far as I understood it, the robot game would be turn based. So if things get slow, the spectators might get bored, but the gameplay won't be affected. Right. Sending the complete map? Not necessary! No, just the data of the robots. Which raises the question which data a robot should have and which are sent to the other robots: Public: - Position(of course) - alive sign (so other robots will know whether a robot is still in play) Private: - Energy Or would it be more fun if all robots would know about each others energy level (I see complete hordes of robots turning against the weakest :-)) Drop is to drop an energie-packet, so smeone else can pick it up. Only useful when playing in teams. You could use an energy packet as a kind of "lure" to ambush another robot... Ow, advanced tactics! Tricky :-) Do you want the program to be the only parameter for the robot, or are there other settings as well? For example, it could be an option to make a robot that receives more damage from attacks, but in return it would move faster. That hasn't been discussed, yet. But we assumed each robot could only move one square (4-neighbourhood) per turn, so an agility/dexterity trade-off is not possible. It could however be possible to divide the available power between defence (shield, whatever) and attack power. About the map: is every square (I assume it uses squares, not hexes or something else) accessible? Or are some squares blocked (obstacles)? Squares are fine :-) I'd say that all squares are accessible. What do we do, however with dead robots? Are they removed from the field or will they stay as obstacles? When a robot scans the environment, does it get info like "enemy at (-2,-3), friend at (1,-1)" or does it know which enemies and friends are nearby: "enemy type 1 at (-2,-3), friend type 3 at (1,-1)"? Not discussed, yet :-) I proposed an inaccurate long range scanner, giving information about a certain part of the playing field, which only delivers the number of robots, energy packets etc. Shevek and I worked up a short range scanner, which gives detailed information about a small environment surrounding the robot. Team play has not been discussed at all (apart from mentioning it w.r.t. the energy packets), so all other robots are of type enemy :-) Maybe a robot can even identify individual enemies and friends, to remember "I damaged that one pretty seriously last time I saw it, so now I'll finish him off". IMHO that should be left to the robot programmer - the programming language for the robots should have the means to do things like that, of course... When using multiple robots in a team, can they communicate? Cooperation would be much more diverse if communication is allowed. And if they can communicate, are they allowed to send as much info as they want per turn, or only a limited amount? I think that team play would be very hard if no communication can take place between the robots of the same party. But, as already stated, team play has not been discussed yet. IMHO team playing makes the whole thing very complex, and simplicity should be the thing to strive for. The more complex we define the possible behaviour, the complexer our programming language will become. That will definitely have an impact on the code size of the robot programs _and_ on the code size of the compiler/parser. How much work space does a robot get? Just for practical reasons (MSXes don't have megabytes of memory) we need a limit. I would say: make it fit in 32k. That makes it easy to put the robot program in e.g. memory pages 1 and 2 ($4000 - $BFFF), have the 'robotz operating system' in page 0 an da lot of workspace for it in page 3... Another thing. How will the process of creating a robot and playing it be like? I mean, will we have one program that reads the robot source code and execute it immediately (probably after compiling it into memory) or do we separate the process of compiling the source code and running the compiled robot. (ehm... shorter: compiler+executor or interpreter or even a JIT-compiler?) I think it would be fun to have the compiler and executor separated. In that way you can create your own robot, and distribute the _compiled_ code, so others can test/play with your robot, but not hack it easily... I'll try to make some time to give a first indication of the robot machine language... Eric (Damn! How can I ever finish my own game when projects like this turn up? ;-)) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX PC local network
Alex Wulms wrote: I have an even better idea. In stead of using port1 and port2 for communication, we can also use port1 for the joystick and port2, with a device like the Ninja Tap, for communication with the neighbouring computers. Like in the following picture: +--+ +-+ +-+ +-+ | comp1p2+ mux p2ap2b mux +-p2 comp2 | | p1-+ |p2b--+ +---p2a| +-p1 | +--+ | +-+ | |+-+ | +-+ joy-stick | | joy-stick +-+ +-+ | | p p +-2-2-+ | a b | | mux | +--+--+ |+-+ +---p2 comp3 | +--p1 | | +-+ joy-stick To keep the communication driver as simple as possible, we can define one port on the multiplexer (mux) as in-only (for example p2a) and the other as out-only (for example p2b). In this case, we have to implement a token-ring network. A bus simply can't do because in a bus we need bi-directional communication for the two systems on the end. This schema can be implemented in very cheap hardware. Ofcourse, it will be a little bit more complicated then only making a cable, but I think it still is not too complicated. Or is it? Kind regards, Alex Hi all, This is what I've been waiting for. This seems (at least to me) the smartest solution. In this way the token bus could be expanded 'without end' and you wouldn't need expensive hardware. If I'm not mistaken, then the only thing you need are wires and connectors. As I have understood this discussion, the MSX has (per joystick port) 3 outputs and (for simplicity) 3 inputs (does it already ring a bell :-) ). This means that you could make a connection as follows (keep in mind that I'm only a simple programmer and don't understand data communications): +data-+ |+---clock---+| || || || +---data+ +---data+ +---data+ || || |+--clock--+| |+--clock--+| |+--clock--+| || || || || || || || || || || || || || || || || || +-ii-oo-+ +-ii-oo-+ +-ii-oo-+ +-ii-oo-+ | MSX A | | MSX B | | MSX C | | MSX X | +-o---i-+ +-o---i-+ +-o---i-+ +-o---i-+ | | | | | | | | | | | | | | | | | +--ready--+ +--ready--+ +--ready--+ | | | +ready+ In simple language this would mean that MSX N signals MSX N-1 it is ready to receive data. MSX N-1 'sees' this and sends it's data (in a sort of I2C way with a data and a clock signal) to MSX N. MSX N removes the message from the ring if it has the token, else it relays the message to MSX N+1. If MSX N has the token, it sends the next message (if any) or transfers the token to MSX N+1. Let me clarify the 'I2C way' of communicating: If MSX N signals it is ready to receive data (ready line), MSX N-1 sets the first bit on the data line and after that alters the clock line. MSX N reacts on the alternating of the clock by IMMEDIATELY reading the signal on the data line. After Xms (depends on the implementation), MSX N-1 sets the next bit on the data line and alters the clock line. MSX N reacts on the alternating of .. After reading the above again, I realize that the wait of Xms could be replaced by toggling the ready line, but this sort of detail could be worked out if the idea seems feasible. I don't know if all of this is feasible, but it seems to me that this is THE most low budget token ring bus possible for MSX. This would also mean that any MSX could be replaced by a PC (which could do the same thing via the parallel port). This would also mean an easy to use and implement driver. It would however mean that every MSX in the ring becomes slower if the bus activity increases. Hope this adds something to the discussion, Jeroen Smael FutureDisk Homepage: http://www.futuredisk.msxnet.org MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
joystick again
Hi MSX people, After a weekend working and thinking about the matter of joystick communications, we have something to say. And maybe after that there will be nothing more to discuss concerning the hardware: The connections of the cable to play F-16 in combat mode are: 1 - 6 2 - 7 6 - 1(this pin numbers are for DB-9 female) 7 - 2 9 - 9 And to play F1 Spirit 3D in battle mode (thanks to Sean Young): 1 - 6 2 - 7 3 - 8 6 - 1(Also for DB-9 female) 7 - 2 8 - 3 9 - 9 LAURENS wrote: I have a proposal about a standard for joystick-connections. Read below about what way I had in mind to let it work like. It is meant to be put in Joystick-port 2 of both computers. My idea was to connect both joystick-connectors like this: pin 6 : 1 (trig1 fwd) pin 7 : 2 (trig2 back) pin 8 : 3 (output left) MAARTEN wrote: SEND (DIN8 male)RECV (DIN8 female) d0 1 ---+ +-- 1 d0 d1 2 -+ | | + 2 d1 ack 3 ---+ | | | | +-- 3 ack gnd 8 ---|-|-|--|-|-|--+--- 8 gnd | | | | | | | | | | | | | | 3 7 6 1 2 8 9 MSX (DB9 female) And what about the auto detect option? I asked a couple of days ago, but there was no reaction, so I'll ask again: Would it be a good idea to connect TRG_A to RIGHT? Using this, we could make an "auto detect" option: the program would be able to see in which joystick port the network connector is plugged in. Also, is it a good idea to connect the ground to the cable shielding? I've seen that on a couple of cables. - Linking joystick ports with a cable is really the simplest and the cheapest way to connect two or more MSX computers. - Everybody agrees that the basic pin connections are 1-6, 2-7 and 8-3. That keep the compatibility with the old games F-16 and F1Spirit3D. - The cables for F-16 and F1Spirit 3D were made to connect only two computers, using one joystick port. Conneccting more than two MSX computers with these cable would force the use of the two joystick ports. It's too bad. - Maarten found the solution. Using only one port we can connect several MSX computers, keeping another port free to use the joystick (for a game) or the mouse (for an application). And for two computers, the cable keeps the compatibility with F-16 and F1Spirit 3D cables. - Is NOT good to standartise that the cable will be always in port 1 or port 2. If you have a MSX with problems in the specified port, you won't be able to connect it... - So, The port can be 1 or 2, and the new softs MUST detect in which port is the cable, though F-16 and F1Spirit3d need the cable in port 2. - DIN-8 has too much pins and is hard to obtain in some places. The DIN-5 connector is enough for us and more easy to find. SEND/OUT (DIN-5 male) RECV/IN (DIN-5 female) NC 5 5 NC out0 4 ---+ +-- 4 in0 out1 3 -+ | | + 3 in1 in2 1 -+ | | | | +-- 1 out2 gnd 2 --+--|---|-|--|-|-|--++-- 2 gnd | | | | | | | || ext -+ | | | | | | |+- ext | +-+ | | | | | | | | | | | | | | | | | | | | | 3 4 7 6 1 2 8 9 MSX (DB-9 female) DIN 5 DIN 5 MALE FEMALE ------ / 2 \ / 2 \ / \/ \ / 5 4 \ / 4 5 \ / \/ \ \ 3 1 /\ 1 3 / \ / \ / \ /\ / \ +-+ / \ +-+ / --+ +----+ +-- extext We think is not important to standartise pin usage or software. If the hardware is the same, the compatibility is guaranteed. There are many ways to establish communication between computers, and the algorythm and the protocol may vary a lot from case to case. So each programmer can use and call the pins just like he wants (D0, ACK, CLK, CTS, IN0, etc...). The maximum transfer speed is theoretically only limited by the MSX clock but the cable impedance (lenght and the existence or not of shielding) may decrease the rate. Then, somebody with knowledge and experience with cables for local networks should give us an advice. But I know that if we need a long distance cable, we can use TTL current drivers, because we have the +5V power supply on pin
RE: My MSX project + protect mode
-Mensaje original-
De: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Enviado el: lunes 30 de noviembre de 1998 12:53
Para: [EMAIL PROTECTED]
Asunto: Re: My MSX project + protect mode
Make it possible to use segments. What I mean is you can set some register
outside the cpu on a value rg and if an address ad is asked by the cpu,
the address that is actually read out is ad+mf*rg, where mf is a
multiplying factor, prefferibly smaller than 64 (use a power of 2 of
course, so you don't actually have to multiply).
Why a small value like 64? A Z380 based system will probably have a
memory size in the order of megabytes, so a value like 64K will be
acceptable as well.
Ofcourse, if a value of 1 is possible, that would be ideal, but maybe
that will make hardware implementation too complex.
[...]
(I don't know why pc-programmers always say
segments are the worst thing ever invented...)
The decision of 16 bytes increments for segments was wrong. That
decision is the reason x86 real mode can only address 1024K, so
indirectly it is responsible for the hated 640K boundary.
Bye,
Maarten
[Isidoro González Márquez] I would add that the wrong decision about
8086 PC segments, which made
them so
hated by everybody, was their
fixed length
(64K) and the absence (lack)
of other mecha-
nisms associated to modern
segmentation
(memory protection, read-only
possibility,
etc.).
[Isidoro González Márquez] One of the worst aspects of Z80 is the lack of
the possibility of addressing
relative to
PC. That would make programs
capable of running
on whatever address. 6809 was
much better
in this aspect. The right
solution is al-
ready invented: virtual
memory. All programs
are written as if they were
running on the
same address and the hardware
makes the
translation "on the fly".
Gyermo.
begin 600 WINMAIL.DAT
M)\^(C+`0:0" `$```!``$``00!@`(Y 0```#H``$(@ `
M ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0V ! `"`@`"``$$
MD 8`: $```$0`P``, (+``\.``(!_P\!-P``
M``"!*Q^DOJ,09UN`-T!#U0"`US$!S=%C:RYN; !33510`US$!S
M=%C:RYN; ``'@`", $%4TU44 ```,P`0T```!MWA
MW1A8VLN;FP``P`5# $#`/X/!@```!X``3 !#P```"=MWA
MW1A8VLN;FPG```"`0LP`0```!(```!33510.DU36$!35$%#2RY.3 ,`
M`#D`"P! .@$`/9?`0T```!MWA W1A8VLN;FP``@'W
M7P$W`($K'Z2^HQ 9G6X`W0$/5 (`;7-X0'-T86-K+FYL
M`%--5% `;7-X0'-T86-K+FYL```#`/U?`0,`_U\``@'V#P$$
M`I% `02 `0`B4D4Z($UY($U36"!PF]J96-T("L@')O=5C
M="!M;V1E`!+`06 `P`.S@,```# ``#8``0!)`0$@@ ,`#@```,X'
M# `'``P`$@`9``$`( $!"8 !`"$W,T%#0C!%,$,U.$1$,C$Q034Y,3 P
M03 R-#4Q-D(P-@#\!@$#D 8`N D``"$+``(``0L`(P```P`F
M```+`"D```,`+@```P`V``! `#D`8+OD#-4AO@$`' `
M`0```"(```!213H@37D@35-8('!R;VIE8W0@*R!PF]T96-T(UO94"
M`7$``0```!8!OB'5#-C@L*QUC41TJ61`* D46L!X,`04`
M``!33510`!X`'PP!% ```=Y97)M;T!G=6=U+G5S86PN97,``P`
M$%(;`J8#``0JP4``!X`"! !90```"TM+2TM345.4T%*14]224=)3D%,
M+2TM+2U$13I-2U1(55523D5 4U151%1514Y,4TU44#I-2U1(55523D5 4U15
M1%1514Y,14Y624%$3T5,.DQ53D53,S!$14Y/5DE%34)2140``@$)$ $`
M``"2!@``C@8``-8+``!,6D9U4Y)*0,`"@!R8W!G,3(U!C(`^ M@;FS,#@Z
M,@'W( *D!0"`-H@0K V5T,"!,$5""= 20($=O=@-X \"@P!0`]0"`'!R
M3(V( 3`H!]"H (R" [FPEO#C U`H *@75C`%#M"P-C$J(+PS@*H@J$"H3A
M"S!L:3,V`4 7( % %Q-0$A %D'02E#$V( HMI)-"?!S86IE\B %LEG"X '
M0!J3%]8/:090L3:9I+3$TQC0!0!CP,3@P`4 ,T$$,V(@14Z#(-B`1%P
M32Y++G0N2 )U"'!N94!S='4F9"!@"E N;@,@6U.P3510.B _(45=%]41'V!%
M;G8',1O('QE;!^G"D @T 0@#T @T0$`(YO)!E!M )"$E\C$Y.3@F\#(Z
M5#4S([=0"L!A'Z=M;'-X(/$`T[EMAIL PROTECTED]=)S)8!T;Q^G4A^0!=!R0716" 9
MD1LP @_BLKXAG"*/ $1P_'4H8]$L7;PJ /@7086L;0GI!4!P;P00:0)@
MT JD-0@=1% (!% 9P `C"PRX@5Q$0!4!)*/ F90.1! `@0A@(/_`Y$1
M03) `W ;0 EPY A`.\$D#!6" RLDF`1(@T"'#? T``(@($@=@= 2PI0
M-.!G-Q!N9#$09O,WP3090) 01)( SHFQAS#P-_!B*Y V=2Q_,%8VCAV
M$B S$3DB!U?0= ;"N0"7 X\37Q.1-D$"MM9BHWH"P@=Q\V@":A/: Y$S!6
M;75LWG0%(#R "X WL8\(06POSWP$U !$09Q`F KD',`P \\!'1.Z$#H#8T
M("C7,A(W(#%0=Q'1;S@@$X#_0S P5@6@"' 10#WP-* ST[DDDXG!4 \)Q$0
M=C'#^3]F*2X7VC+P*Y W($%C+SU/ P\4(P/Q.0(%J,QZP.: Y4#F!WDU
M,?YM/@`#$
Translation Tilburg mail
Hi! It seems to have gone wrong... But here is the translation: X-Mailer: exmh version 1.6.7 5/3/96 To: [EMAIL PROTECTED] Subject: Re: NEWS TILBURG 1999 (English) In-reply-to: Your message of "Thu, 17 Dec 1998 23:48:17 +0100." [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain TILBURG 1999 is ON Sorry dat we nog niet eerder hebben gereageerd, maar hierbij de huidige status m.b.t. de beurs Tilburg 1999 ! Sorry that we had not responded earlier, but in this mail we'll inform you about the current status of the Tilburg 1999 MSX Fair! De reden achter de "stilte" komt zeker niet door gebrek aan interesse van ons, integendeel, maar juist door het uitstellen van de beslissing in de hoop dat we nog op de oude voet door konden gaan. The reason of the 'silence' was not a lack of interest of our side, on the contrary, we just wanted to postpone the decision in the hope we could organise the fair as usual. Het ziet er echter naar uit dat we de beurs in zijn oorspronkelijke grootte niet meer kunnen organiseren. But it seems that we can't organise the fair in its original 'size'. Dit betekent echter nog niet dat Tilburg 1999 helemaal van de baan is !! This does not mean that Tilburg 1999 is totally out of the question Allereerst een paar dingen op een rijtje... First some facts... Tot nu toe (15 december) zijn er slechts 18 kramen gereserveerd door standhouders. Als wij zelf ook 4 kramen vullen, komen we daarmee op 22 stuks... Nu is het zo dat de Bremhorsthal pas redelijk gevuld is als er 60 tot 70 kramen staan. Until now (15 december) there have been only 18 stand-reservations. If we use 4 stands ourselves, there will be 22 stands in use. But the 'Bremhorst-hal' (the building of the fair) is only filled reasonable when 60 to 70 stands are in use! Met dit aantal reserveringen willen en kunnen wij zeker geen gebruik maken van de Bremhorsthal. Natuurlijk komen er altijd nog aanmeldingen bij, maar het verschil tussen nu (22 kramen) en de benodigde 60 stuks is wel heel erg groot. With this number of reservations we cannot (and don't want to) use the Bremhorsthal. Of course there will come more reservations, but the difference between the 22 stands we now have and the 60 we need is pretty big! Wij vinden het niet juist het publiek te ontvangen in een grote zaal waar de standhouders in een hoekje opgesteld staan. Dit zou zeker geen goed doen aan de MSX. We don't think it's right to welcome people in a big hall where the exhibitioneers are in the corners... This would not do good to MSX. Bovendien is de huur van de bremhorsthal inclusief kramen, electra, meubilair, ect, vrij hoog ( 4000 tot 5000 gulden ). Furthermore, renting the Bremhortsthal is pretty expensive: between 4000 and 5000 NLG. Wij verwachten dat door het wegvallen van MCCM, welk blad voor ons van groot belang was om de doelgroep over de beurs te informeren, het aantal bezoekers zeker minder wordt. The Dutch MSX Magazine MCCM always informed lots of people of this fair, and since this magazine has quit, we think there will be a significant smaller number of visitors. Het is natuurlijk altijd leuk elkaar weer te ontmoeten, maar de kans is dus groot dat het dan voor ons een erg duur onderonsje wordt. It's always nice to meet each other again, but there's a big chance this 'meeting' would be very expensive for us. Ik wil jullie echter vragen nog een paar dagen geduld te hebben, want wij zijn in onderhandeling voor een andere ruimte ! De opzet wordt dan echter wel iets anders. Actually, I wanted to ask you to wait a few days longer, because we're trying to get another place for the fair! The set-up will be a little bit different then. WIJ WILLEN DAN EEN GROTE MSX MEETING ORGANISEREN in een wijkcentrum. WE WANT TO ORGANISE A BIG MSX MEETING in a community-centre. De kosten zullen dan voor de deelnemers laag zijn ( 30 gulden per 3 meter tafel, inclusief 3 standhouderskaarten ) en een geringe toegangsprijs ( 2,50 ) voor de bezoekers. Voorlopig gaan we nog uit van dezelfde datum. The costs for the exhibitioneers will be very low then (30 NLG per 3 metres of table, including 3 exhibitioneer-entry-tickets) and a small entry-fee (2.50 NLG) for the visitors. For now we assume the date will be the same. (24th April) Het is echter nog steeds van groot belang dat we op voldoende deelnemers kunnen rekenen, en dat jullie deze dag promoten en bekend maken bij alle belangstellenden ! But it's still of extreme importance we can count on sufficient participants, and that you will promote this day to all people that might be interested! STOP DUS MET DIE NEGATIEVE BERICHTEN EN ZORG DAT IEDEREEN NAAR TILBURG KOMT SO STOP THESE NEGATIVE MESSAGES AND MAKE EVERYONE COME TO TILBURG!!! LAAT ONS WEL EVEN WETEN WIE ER MEE DOET AAN DEZE DAG BUT LET US KNOW WHO WILL PARTICIPATE IN THIS MEETING Stel dus niet uit en laat snel middels een
Fw: New joystick communication standard proposal
-Oorspronkelijk bericht- Van: Werner Augusto Roder Kai [EMAIL PROTECTED] Aan: [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] CC: [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Datum: maandag 17 augustus 1998 8:11 Onderwerp: New joystick communication standard proposal (I'm unable to send mail to the msxmailinglist because my account at basemail is off-line. Please forward this to msxmailinglist for me. Thnx) Hi MSX people, After a weekend working and thinking about the matter of joystick communications, we have something to say. And maybe after that there will be nothing more to discuss concerning the hardware: The connections of the cable to play F-16 in combat mode are: 1 - 6 2 - 7 6 - 1(this pin numbers are for DB-9 female) 7 - 2 9 - 9 And to play F1 Spirit 3D in battle mode (thanks to Sean Young): 1 - 6 2 - 7 3 - 8 6 - 1(Also for DB-9 female) 7 - 2 8 - 3 9 - 9 LAURENS wrote: I have a proposal about a standard for joystick-connections. Read below about what way I had in mind to let it work like. It is meant to be put in Joystick-port 2 of both computers. My idea was to connect both joystick-connectors like this: pin 6 : 1 (trig1 fwd) pin 7 : 2 (trig2 back) pin 8 : 3 (output left) MAARTEN wrote: SEND (DIN8 male)RECV (DIN8 female) d0 1 ---+ +-- 1 d0 d1 2 -+ | | + 2 d1 ack 3 ---+ | | | | +-- 3 ack gnd 8 ---|-|-|--|-|-|--+--- 8 gnd | | | | | | | | | | | | | | 3 7 6 1 2 8 9 MSX (DB9 female) And what about the auto detect option? I asked a couple of days ago, but there was no reaction, so I'll ask again: Would it be a good idea to connect TRG_A to RIGHT? Using this, we could make an "auto detect" option: the program would be able to see in which joystick port the network connector is plugged in. Also, is it a good idea to connect the ground to the cable shielding? I've seen that on a couple of cables. - Linking joystick ports with a cable is really the simplest and the cheapest way to connect two or more MSX computers. - Everybody agrees that the basic pin connections are 1-6, 2-7 and 8-3. That keep the compatibility with the old games F-16 and F1Spirit3D. - The cables for F-16 and F1Spirit 3D were made to connect only two computers, using one joystick port. Conneccting more than two MSX computers with these cable would force the use of the two joystick ports. It's too bad. - Maarten found the solution. Using only one port we can connect several MSX computers, keeping another port free to use the joystick (for a game) or the mouse (for an application). And for two computers, the cable keeps the compatibility with F-16 and F1Spirit 3D cables. - Is NOT good to standartise that the cable will be always in port 1 or port 2. If you have a MSX with problems in the specified port, you won't be able to connect it... - So, The port can be 1 or 2, and the new softs MUST detect in which port is the cable, though F-16 and F1Spirit3d need the cable in port 2. - DIN-8 has too much pins and is hard to obtain in some places. The DIN-5 connector is enough for us and more easy to find. SEND/OUT (DIN-5 male) RECV/IN (DIN-5 female) NC 5 5 NC out0 4 ---+ +-- 4 in0 out1 3 -+ | | + 3 in1 in2 1 -+ | | | | +-- 1 out2 gnd 2 --+--|---|-|--|-|-|--++-- 2 gnd | | | | | | | || ext -+ | | | | | | |+- ext | +-+ | | | | | | | | | | | | | | | | | | | | | 3 4 7 6 1 2 8 9 MSX (DB-9 female) DIN 5 DIN 5 MALE FEMALE ------ / 2 \ / 2 \ / \/ \ / 5 4 \ / 4 5 \ / \/ \ \ 3 1 /\ 1 3 / \ / \ / \ /\ / \ +-+ / \ +-+ / --+ +----+ +-- extext We think is not important to standartise pin usage or software. If the hardware is the same, the compatibility is guaranteed. There are many ways to establish communication between computers, and the algorythm and the protocol may vary a lot from case to case. So each
Re: Bigger sector numbers
Hi all, Maarten ter Huurne [EMAIL PROTECTED] typed on his keyboard: I proposed earlier to use for both BIOS-routine 0144h and diskROM-entry 4010h the following change, to allow the use of bigger sector numbers: But you still haven't convinced me (and some others) why 4010 should be updated instead of creating a new routine at a new address. The issue here comes down to: Why have programmers learn the use of a new call, make every single piece of software that PERHAPS might still have some use, useless 'by definition', and go through the trouble of definining new entries, when there's no real need for it? My view on this is simple: define new methods/entries etc., when there is a CLEAR ADVANTAGE to be had from this. If no such clear advantage exists, use existing entries/methods if possible, this will simply minimize the overall impact, and make acceptance easier. For those of you who are worried about older programs messing up HD partitions, I could think of 2 solutions: a) Doesn't your harddisk-interface allow you to simply disable a partition? If yes, do so, and you've got no problem here. If no, I suggest you get that fixed first. b) I have never liked it, that having a HD interface, in most cases meant that floppy drive letters A B moved to F G or whatever, and changed again when removing or adding partitions. Instead, I would much more prefer the PC method here, to give floppy drives fixed letters A B (who's got floppy drive C or D anyway?), and start harddisk partitions with C, D, etc. Doing so would fix many of these old program's problems as well. It's not easy for the programmers of the HD BIOS. To fetch the sector number, the memory it is in must be selected. But by the time the HD BIOS looks up the sector number, a lot of slot switches have occured. Reading the correct values would take an inter-slot-read, which is slow. If called by a user program, all user memory will be selected when the driver ROM is called, except in page 1. If the BIOS routine is called, the system can copy the value to a save location in page 3 or elsewhere in case it was in page 1, or leave it alone otherwise. Calling driver entry 4010h directly from an application program would be illegal (as it is now, strictly speaking), with the parameters in any other than page 1, no problem anyway. If called by the system, such a sector number would be somewhere else than in page 1 anyway. So in all cases, this will be directly available for the driver, no inter-slot access required. An example: If register DE contains this pointer: PUSH DE POP IX then: (IX)=sector number bit 0-7, (IX+1)=sector number bit 8-15, etc. no direct limit on the sector number's size here either. For the BIOS/diskROM entries, it would pose a problem to define new entries; where to place such a new entry? #4034 and beyond, plenty of space left. Available, but would require the data/software there to be moved elsewhere, and every routine calling/using the data on this address to be adjusted. That's the real problem with this, simply a lot of work, that might be avoided. If called with A=2 (get info on FAT16 support): returns: A=0: no FAT16 support A0: FAT16 supported Any extra info to be determined later, if necessary More useful would be a call that tells you which filesystem is used on a particular drive. Imagine a system with both a FAT12 and a FAT16 partition active. Knowing that FAT16 is supported is not enough, you have to know on which drives. To make this more general: you want to ask which filesystem is used on a certain drive. That's another matter: what filesystem is used on a particular drive, is depending on the medium/disk in that drive, not on the system that handles it. My proposal for this new function call only concerns the system's ability to handle it, that is, the presence of new functions/variables that allow access to it, possible new data structures used etc. In other words, this new function would simply indicate wheter the system is AWARE of these big sector numbers, FAT16 etc., and if the functions/data structures to deal with it are in place, not whether it's actually used or not. Only thing left then, would be finding a way for the system, to determine if a driver supports 32-bit sector number I/O, or not. I suggest using one of the existing diskROM-entries (preferably one of those besides 4010h), with some special input value, to determine this. I suggest using a "magic number" identification. A short number or string that is specific for 32-bit sector number compatible device driver ROMs. Just like "OPLL" is used for FM-PAC. A good idea. You might use the fact that all existing drivers that I know off, have most of the entries filled with a JP instruction. You could take the destination address of this jump, subtract a few bytes, and look for such a signature there. You
Re: Breaking the 32Mb/partition limit
Hey, this is getting animated! ;-)
Indeed cluster have been used since the first DOS release. But for some
reason MS-DOS introduced 32Mb partitions in version 4.0. Does anybody know
why?
Obviously, for the same reason as I initiated this discussion: 32Mb per
partition is too small!
FAT16:
Not bad! Imagine 2Gb partitions on your MSX!!
Note that using 64 sectors/cluster gives a huge memory demand for your MSX.
64 sectors is 32K, so every cluster in memory eats up 32K of your precious
MSX memory.
You are right, I don't think on that before!
For FAT16 this is not such a big problem, since if you have enough money
for a 2Gb harddisk for your MSX, you can probably also afford a 4Mb memory
Hum... are you sure of this reasoning? Well, anyway if we modify MSX-DOS 2
or whatever software for controlling 32k clusters, we can make it for 256K
computers only. It is time to leave the standard of "for 128K"!
maper. But for FAT12 this is a real problem, since cluster sizes are 16x
larger than FAT16 for equal partition sizes.
Look at this table I found in the Microsoft page:
Drive Size FAT Type Sectors Cluster
(logical volume) Per Cluster Size
--- ---
(Floppy Disks) 360K 12-bit 2 1K
720K 12-bit 2 1K
1.2 MB 12-bit 1 512 bytes
1.44 MB 12-bit 1 512 bytes
2.88 MB 12-bit 2 1K
(Hard Disks) 0 MB - 15 MB 12-bit 8 4K
16 MB - 127 MB 16-bit 4 2K
128 MB - 255 MB 16-bit 8 4K
256 MB - 511 MB 16-bit16 8K
512 MB - 1023 MB16-bit3216K
1024 MB - 2048 MB16-bit6432K
MS-DOS determines the FAT size based on the number of clusters.
If there are 4085 or fewer clusters, a 12-bit FAT is used.
If there are 4086 or more clusters, a 16-bit FAT is used.
Interisting, isn't? FAT12 is only used for partitions smallest than 16Mb!
So, if using FAT16, we can use partitions of up to 511 Mb (maybe 1023 Mb?)
with the same MSX memory requirements as in the case of FAT12 with 32Mb
partitions. Or we can make partitions biggest than 511Mb usable only by 256K
RAM users.
The problem is that the current way of communicating with the hard disk
interface is using a CALL that expects the sector number as a 16 bit value.
So to allow 32Mb partitions, you need a new way of CALLing the hard disk
interface. Hard disk interfaces should then be equipped with a new ROM that
implements the new CALLing standard.
I have a Mega-SCSI controller. The programming manual is in japanese, but I
can interpolate something from the explanation of the CALL you mentioned,
DSKIO at #4010, included in the last pages of this manual. Some of the input
parameters are:
C: Media ID (some japanese comments here)
C (bits 6-0): First sector number, bits 22-16 (some japanese comments here)
DE: First sector number, bits 15-0
Maybe this is the modification you mentioned above? We have 23 bits for
specify sector numbers, and this is enough for 4 Gb! So, maybe the hard disk
controllers are already prepared for big partitions and the DOS 2 is the
only problem.
Anyway, I think that this problem can be solved with a drivers system. Even
if the PHYDIO routine of the controller is limited to 16 bit sector numbers,
the whole hard disk can be controlled by controller-specific ports, right?
Then we can modify MSX-DOS, so instead of calling PHYDIO, it must call the
appropriate driver previously loaded in RAM.
And we have a touchable example of this: the MSXCDEX driver for Mega-SCSI.
This is a perfect example of wath I want to do. A driver for Mega-SCSI is
loaded in a new RAM segment, and the DOS 2 code segment is patched (as well
as the hook #F252) for redirectionning the disk related DOS function calls
to the driver. Results: the CD-ROM is treated as a normal drive,
write-protected of course. And if it can be done for CD-ROM, doing it for
FAT 16 disks must be much easiest!
I don't think anyone wants to use a 32Mb partition under DOS1. Imagine
100Mb of files without the ability to create sub directories...
If we just leave floppy formats as they are, DOS1 users should have no
problems.
MSX-DOS 2 makes 10 years in the 98. I think it is time to standarise it and
abandon MSX-DOS 1 at once!
Yes, this is the main problem. Is for this that I request for information
about the DOS 2 internals!
Hard disk interfaces exist that have DOS2 internally. Maybe the
manufacturers of those interfaces have a source code of DOS2?
ESE Artsit's factory staff must have a lot of DOS 2 technical info, because
the Mega-SCSI installer modifies the DOS 2 kernel before putting it in SRAM!
Besides, for making
Re: Robotz 0.2
At 12:06 PM 1/5/99 +, you wrote: bit 0 or 1, FALSE or TRUE You mean FALSE = 0 and TRUE = 1? I should kill the "FALSE or TRUE" part here, I guess... Actuallt, I'd like any non 0 value to be TRUE :-) byte signed or unsigned 8-bit value This vague "signed or unsigned" will cause trouble... Absolutely 'non 0' (eh.. TRUE, that is) :-) The problem is that I don't know if it suffices to define only signed values. (Only unsigned values definitely won't...) address word in range $ - $3FFF (15 bit) That's 14 bits... I meant $ - $7FFF, 15 bits, 32kB address space :-) (Which is quite a lot, come to think of it, maybe I should limit it to 14 bits/16kB) flag Z, P, N, NZ, NP, NN (bitmask over flags status reg) If you use a bit mask, all nonzero values should be interpreted as "TRUE". In your definition, only 1 was interpreted as "TRUE". Ok, as stated above, I'll change that... I think nowhere in the document is stated what the flag mean. I guess "Zero, Positive, Negative, Non-Zero, Non-Positive, Non-Negative", is this true? At the description of the flag register, the meaning of Z, N and P is defined. NZ, NP and NN are not defined, that's true. The machine has two stacks. One for calculations and parameter passing (a-stack) and one for storing return addresses for CALL instructions (c-stack). The a-stack is located in memory, the c-stack is machine- internal. Why do you want the a-stack to be located in the virtual machine's memory? That will only tempt people to mess with it. True. I put it in memory because thew stack usualy _is_ in user space memory (although there exist uPs with an internal stack...) [META: I need some input here. Should there be a fixed address range for the stacks? If you put them in memory, yes. Another possibility is to introduce a few registers (read/write), which set the stack ranges. In that case a user can define his own stack sizes and make efficient use of the available memory... But I suggest you don't put them in memory, in that case you only have to say something about their size. True. Any other arguments in favour of putting them outside memory, apart from the possibility to mess with the stacks? Could it be possible to intergrate the two stacks into one? I think they can, but I need more time to think this through. Me too. At least till the wqeekend, when I can recover my lecture notes on compiler building :-) 2.2 Status Registers The registers are divided into two classes: public and private. ^ Please state "status registers" explicitly here (you do that in the rest of the paragraph, but not in the first sentence). Ah, ok. If you swap paragraph 2.2.1 and 2.2.2, readers will see the description of the public status registers first, so they can understand this information (alive and action fields). Hm, not a bad idea. I'll do that... Is the scanner range 2 squares or is this just an example? It's an example. The scanner ranges upto the borders of the playing field. I'll make that more clear. (Maybe that should come in the game description) Syntax: MOVE The lower 2 bits of stacktop indicate the direction in which the robot is moved: 0 - north 1 - east 2 - south 3 - west Why not use the same encoding as used for scan? Since diagonal moving as apparently not allowed, you could simply use bits 1 and 2 instead of 0, 1 and 2. That's one sensible solution, another could be limiting the possibility of the SCAN command such that it can only scan north, south east and west and take the northwest etc out... Syntax: ATCK The ATCK command makes the robot attack another robot at a neighbouring square. What if there is no robot in that square? Is the empty square attacked or is there no attack at all? Since attacking costs a turn, there is a difference. IMHO, the empty square should be attacked, regardless of whether the square is actually occupied or not and it takes a turn. Question is whether you will lose energy attacking an empty square... A similar argument holds for the MOVE command of course. What should happen if a robot wants to MOVE to an occupied square? IMHO, only the result of the MOVE should be ignored: energy is lost, turn is over, but you did not move. Syntax: DROP Drops the amount of energy indicated by the stacktop from the energy supply onto the field. When the value of the stacktop is 0 or negative, no energy will be dropped. When is a "signed or unsigned" value negative? When the N flag is set :-) [META: I dropped the SKIP command, as the same effect can be achieved by PUSH 0 followed by DROP. Big advantage is that all action commands now have the same syntax and the same stack behaviour! And a command less further simplifies the machine, of course :-)] Usually, I agree, but I'm not sure it's a good idea here. If someone uses the "public.action" register to remember its previous action,
Brand New MSX Database on-line
Hello, I don't know whether you'll still recall my first posting into this mailing list. It was kind of a self-introduction to the MSX list. I mentioned there that I used to play with my MSX1 Philips VG-8020, and that now (then) that I had discovered about MSX emulation was becoming an MSX-junkie. :) BTW, my first and only cartridge was "Loderunner" I still love that game. I made that posting by mid-november. Well, during these weeks I have posted some messages and found that people here do help each other when in doubt, also i've been able to dowload real nice pieces of software from different MSX sites. But this wasn't being fair. I was thinking: The MSX community has done precious things expecting not to make any profit out of it (well, some do want to), just to keep MSX up 'n' kickin'. So I asked myself what could I do in exchange for the community and here is my answer: I've been working pretty hard on making an MSX software (by now, games) database. But I wanted it cooler, so I contacted a guy, Martijn, in The Netherlands whom we all should be thankful to for his kind and not-profit interest and devotion, and talked to him about making the database Internet-available, so that other MSX-freaks could just benefit from having a valuable reference source whenever they wanted to look for some piece of software. Martijn kindly offered himself and his script on behalf of the MSX community, and with some modifications on the script, now, the database can be reached and queried online. We also should be thankful both to Egor G. Voznessenski and Sean Young who have kindly offered themselves to provide me with HD space where I can store the database and the cgi. If it weren't for you two, this would be pretty much of a dream by now. The database is called MSX ROMS INTERNET DATABASE. Every record in it has the following fields: ROM: name of the rom SYSTEM: msx1, 2, 2+ or turbo-r TYPE: cartridge, tape, disk (accounts for the source it was ported from) TITLE: any doubt? SIZE: " COMPANY: " YEAR: " And any of that fields can be queried. What's more, there's an ANY search criteria option which will look for your search string in ANY field, not just one single field. The database is now in version 2.0 (prior versions were beta) and is currently storing 1,100 records!! which should be a pretty good starting point, isn't it? Data has been compiled from different sources, be it web or ftp sites, however much data comes from mayor sites like komkon, funet, Sean Young's Konami site and a few other site I may have forgotten. Hey! Don't get mad at my just because I didn't cite your site! :) As you can imagine, NOT every record has all of its fields filled in, since I haven't been able to collect all of that data. Sorry, I am not GOD. :) And here comes what probably should be a good point of debate in the list: I have found, and you all certainly too, that the same game has different filenames so it happens that when you're downloading one, you're not positive on whether you haven't got that game already on your HD. So to make a little bit of order out ot this caos I have named the ROMS according to a logical principle by means of which no single can game can have two filenames, and two similar games do have different filenames. To put it clear: I have registered 5 different Golf games. It happens that when I was collecting the data, nearly all of this golf games had the very same filename, golf.rom, which caused confusion since I didn't know whether these games were all the same, or they belonged to different companies, as a result, all I had was TOTAL CONFUSION. That is why I decided to give each game a definitive independent filename so that I and the MSX community by default, would have no more confusion. Look at this example, it speaks for itself. C-GOLF.ROM CARTRIDGE CASIO WORLDOPEN BORAM 86 GOLF.ROMMSX1CARTRIDGE GOLF16 KONAMI 0 KGOLF.LZH MSX1TAPEKonami's Golf 0 MINIGOLF.ROMCARTRIDGE MINIGOLF0 NAMCOT 85 QGOLF.LZH MSX1TAPEQueen's Golf0 The same happened with billiard games and several many other: BILLIARD.LZHMSX1TAPEComputer Billiards 0 BILLIARD.ROMMSX1CARTRIDGE BILLIARDS 8 KONAMI 0 CBILLIAR.ROMCARTRIDGE COMPUTER BILLIARDS 8 KONAMI, SONY83 For the sake easyness I've followed the "guidelines" that the mayor MSX soft sites have stablished for their filenames in the index.txt files, therefore, many filenames have not been changed at all, only those who needed it. So this database has also been set up for the sake of clarity amongst the MSX community. I've already emailed the guys in charge at funet, komkon, and Sean telling them about this database, and asking them to mail me whenever they add a
Re: Robotz - v 0.3
Hi, Add that signed numbers are stored in two's complement format. Agree. Consider it done. Have you looked yet at the possibility of integrating the two stacks? Yes. But only after I put version 0.3 online :-) To integrate the two stacks is not that difficult, but it complicates stackhandling a little. Apart from the normal stackpointer, there's an additional pointer, which I will call RAP (return address pointer). When a CALL is executed, first, the RETurn address for the CALL is pushed on the stack _and_ the current value of the RAP. Then, the RAP gets the current value of the stack pointer. The RET resets the value of the stack pointer to the value of the RAP; then the new RAP value and the return address are popped from the stack. In this way you create within the stack a linked list of (return address, next pointer) pairs, which are separated by 'local' stack data. What about defining an "out of range" code? Every square out of scanner range will have that property when scanned. Advantages: - you know what to return when for example env[3][3] is requested - rules like "damaged robots will have reduced scanner range" can easily be added later Hm, I'll think about it :-) After a robot drops energy, it's possible for a robot and an energy supply to occupy the same square. Hm, that means that the env[][] as it was wouldn't function anyway - I'll redesign that part... scan.n_supplies - (byte) Maybe it's better to report the amount of energy (sum) instead of the number of supplies? That's also a possiblity. I'd say that if you look at an energy supply at a long distance it's easier to decide _whether_ it is there, than to figure out the size of it. That's in favour of the .n_supplies variant. On the other hand, When the total amount of energy is returned, it's easier to make a move in the right direction (just try to get the largest power supply :-)) I think the scanner should have limited range, although it should be a lot larger than the range of the env variable. Well, then make a proposal :-) How large should it be? Another, related question: how large should we make the playing field? Maximum would be 32.768 x 32.768 squares (signed 16-bit word maximum value), but I guess that's a little too large :-) [META: Would it be more fun to define a scanner that only scans in a line? so: scanning e.g east would be defined as: . . . . . . . . . . . . . X + + + + . . . . . . . . . . . . ] No, that would make the scanner too limited. Syntax: SKIP flag Opcode: %0001ifpz ... mask | name I F P Z | +--- 0 0 0 0 | -(not used - will never jump) This is the "NOP" for the abstract robot machine! Right, but has another opcode. I could redefine the opcode, so it has opcode $00 of course :-) (Don't say "not used", let people decide what they want to use and what not.) Ehm, If I define that $10 is an illegal instruction, then it's not used :-) 1 0 0 0 | -(not used - will always jump) This is a useful instruction: it allows you to jump over the next instruction. Since a SKIP requires less bytes than a JUMP, the compiler can use it to optimize the code. Ok, I'll scrap the words "not used", here... What if you changed "negative/positive" into "sign/no sign (S/NS)"? In that case, you could make "SKIP" mean "skip always" and "SKIP N" mean "skip never (NOP)". By the way, I really like the idea of "opcode made of truth table". Me too :-) I just got the idea from the z80 LD instructions where the register is encoded in the opcode... Syntax: JP address Opcode: $20 ll hh where address = (hh AND $3F)*256+ll I'm not sure whether the "AND $3F" is actually useful. Maybe you should simply let the robot break down when the address is out of range. Hm, not nice :-( Although... I even think that we should have the "robot EXE format" tell which part of the RAM will be used for code and which part for data. Executing data or reading/writing code should be illegal. The reason for this is that it makes debugging much simpler. If the robot bytecode interpreter reports "robot shut down: writing to code area at $1420", you can easily spot the error in your program or compiler. However, if the write is allowed, you will probably see the robot do very strange things without having a clue what's wrong. Hm... I'll sleep on it over night... Syntax: PSHB byte ... Maybe you can better describe it as "byte is fetched, then sign extended, resulting word is pushed to the stack". Hm, ok. Suggestion: Syntax: PSHE index Opcode: $37 nn where index = nn Pops two words from the a-stack. The topmost is called y and the other one x. Depending on index, a byte specified by one of the following environment items is pushed to the a-stack: index = 0 env[x][y].contents index = 1 env[x][y].data index = 2
RE: computer to sell
You wrote: From: Massimiliano Riondino Sent: zaterdag 2 mei 1998 15:22 To: [EMAIL PROTECTED] Subject: Re: computer to sell ALBERTO VALVERDE wrote: Good day, all. Aalso to you Also, I'm still interested in buying a MSX2/MSX2+ or even a Turbo R if the price is right. Since shipping is quite expensive, I would prefer buying from someone in Sweden. I have MSX2, MSX2+ and Philips 8280 upgraded to MSX2+ to sell, also a lof of MSX hard, later I will sen you a list price when I have time. I live in Finland. Regards. Alberto __ Get Your Private, Free Email at http://www.hotmail.com MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) Hi frome Italy!!!I'm an MSX user and I've read with attention your message... I'm interesting especially to MSX 1 hardware, can you send me a complete list with all that you have, the condition and the price???... Bye Massimiliano Hello Massimiliano, I don't know if Alberto has MSX-1 stuff for sale, but I know someone who wants to sell his MSX(-1) stuff. Look in the attachment what things he has for sale. ( btw it's a lotus 1-2-3 file) greetz arjan [EMAIL PROTECTED] Msx.wk1
Re: Bigger sector numbers
Hi all, To refreshen your memory: I proposed earlier to use for both BIOS-routine 0144h and diskROM-entry 4010h the following change, to allow the use of bigger sector numbers: if bit 7 of drive number=0, then all parameters as usual, if bit 7 of drive number=1, then DE-register = pointer to 32-bit sector number (instead of containing 16-bit sector number itself) I would like to add one condition for the implementing routine here: the memory location passed this way should not be modified, only used as an input parameter. All other parameters unchanged. This would insure 100% compatibility, have a negligable impact on performance, and easy to use for programmers. I think it was Jon De Schrijder [EMAIL PROTECTED] who proposed to simply put the lower part of the sector number in DE-register (as usual) and store the high part directly in some memory location. Simple and fast, but with 1 big problem, as with the other methods proposed: where to store the rest of that sector number? A memory location to use for that would have to be: -Fixed; if this location would be a variable itself, you might as well use my method -Free to use for this purpose, which means it should not be corrupted by any other system software that might be executed during the call (interrupts can be on as well, so software hanging on an interrupt-hook might call BIOS-routines during the disk-I/O call) -It should not corrupt any system variables itself Take your pick! I see another discussion coming, about the single issue of what memory location might be used for this purpose. Once a certain address would have been picked, and a few HDD-interfaces updated using this, it would be very difficult to move this to another location after that. To stop that discussion right here, I would like to point out that the method I proposed, solves that immediately: an application programmer can pick what he/she likes, and no problems with changing an address that was picked earlier. No risk of interfering with system variables either. Therefore I feel the way I came up with is still the best, and right now it's the only full solution for passing bigger sector numbers. Jon also wrote: Does everyone agree on the fact of using 24bit sectornumbers instead of 32? I do I sure as hell DON't ! You'll probably have to update files like MSXDOS2.SYS COMMAND2.COM, some utils like CHKDSK, sector-editor etc. will have to be modified or re-written, updates for the software in HDD-interfaces will have to be made, and if you take 24 bit sectornumbers now, it will be useless by the time this is done. Taking at least 32 bit sector numbers is a tiny issue now, as opposed to 24 bit sector numbers, but if you take too small numbers now, it'll give an enormous amount of (unnecessary) headaches later. Nestor Soriano wrote: It is this simple: FAT16 - max. 2 GB. per partition - 24 bit sector numbers are enough Well, suppose you have that 24 bit sector number support, and you have FAT16 support. Then you want stuff like FAT32 support (plenty of filesystems left!). The system would not support that yet, so what could you do? Simple! Write your own application using that, and do the I/O using low-level sector routines. WRONG! no sector-I/O support for this either. I think if you're making system-extensions now, you should in principle include what exists now, and take into account what you can see coming. Well, I see 10 GB. and bigger drives NOW, and far bigger ones coming (soon). - 24 bit sector number usefull NOW (not in a year), 32 bit sector number support usefull SOON (MAYBE in a year from now, maybe even sooner). 2 things left to be sorted out here: -DOS function calls for this purpose -how to determine if the system supports this big sector number feature? DOS functions - For the BIOS/diskROM entries, it would pose a problem to define new entries; where to place such a new entry? How to pass the extra info? For that reason alone, it was a good idea to use the existing entries, with a small modification to parameters. To be able to call these using interslot-calls, no use of index registers or Z80 shadow-registers was possible. But for DOS function calls, this is far EASIER! I think that indicating a big sector number with bit 7 of the drive number set, is so much compatible, that there is no real need to define new DOS function calls for this. Not doing that, will make sure that it's easy for programmers (same function numbers, same parameters, just set a bit). But: you can use Z80 index-registers on DOS calls! (used for several DOS2 functions, I'm not sure about Z80 shadow-registers though). So, I propose to extend DOS function calls 2Fh 30h (absolute disk read/write) as follows: If bit 7 of drive number (in L register) = 0: all parameters as usual If bit 7 of drive number = 1: DE = low 16 bit of sector number (was: sector number) IX = high 16
Re: Breaking the 32Mb/partition limit
Konami Man [EMAIL PROTECTED] wrote: Hello people... I have a satanic idea flying about my mind: to break the DOS 2 limit of 32Mb/partition limit. Even if I don't have any SCSI device (neither on MSX nor on my PC), I find this idea very interesting ! It could also the problem of number of partitions on a disk and a better "drive letter" use... Let's begin for the beginning. The 32 Mb limit is given by the sectors number limit. Only two bytes are prepared in the boot sector of the MS(X)-DOS disks for storing the number of sectors of the disk/partition, at position #13 and #14 of the sector. Since sector size is 512 bytes, the maximum partition size is 32768K. For your information I'm not enough specialist or DOS evolution historian to ensure the reliability of all the mecanism and their "arrival date"... and also I don't have any harddisk on my MSX. So I hope not to make too many mistakes... MS-DOS 4 and higher uses four bytes, in positions #20-#23 of the boot sector, for storing the number of sectors in partitions higher than 32Mb; in such case, #13-#14 stores the value 0. MSX-DOS 2 stores the string "VOL_ID" in positions #20-#25 as a flag for indicating that the disk has a serial number in positions #27-#2A. Another question is the FAT entry size. MSX-DOS uses a 12 bit FAT, as well as MS-DOS for partitions smallest than a certain number of sectors (I don't know if this number is also 65536). For highest partitions, a 16 bit FAT is used. In positions #36-#3A of the boot sector in disks formatted with MS-DOS 4 or higher you can found the string "FAT12" or "FAT16" referring to the FAT entry size. Addressable range: 2 Mb = 512 bytes * 2 ^ 12 (FAT12) 32 Mb = 512 bytes * 2 ^ 16 (FAT16) (sector size which is assumed constant, even if coded at offset #B) So even with a FAT16 the MS-DOS (up to version 3.3 I think) had a problem for partitions bigger than 32 Mb. MS-DOS 4.0 (or more) allowed to use FAT16 with an extra feature, the cluster, which is a group of sectors, an do, even if the physical read unit is 512 bytes, the assignements are now made per cluster instead of sectors (I guess everyone knows about that), which is the allocation unit. So the number of clusters stays 65536 (and so also the number of files per partition), maximum cluster size is 32 Kb (64 sectors per cluster), allowing up to 2 GB size partitions. But for two (or even three ?) reasons this is now changed using the MS-DOS 7.0"b" from Windows 95b (OSR2 with FAT32): * nowadays disks are between 2 and 8 GB (and even more for some very expensive "Servers aimed" disks) * putting so much sectors in a cluster causes a huge waste of diskspace, most of the files are less than 8 Kb (even less with all the LNK files, batches, GIF from internet, etc...), this waste can be as high as 30 % (yes you've read THIRTY %) of the total disk capacity. * and even maybe that only 6 bits were assigned in the boot sector for the "sector per cluster" (offset #D) value (but I doubt it's the case). Even MSX-DOS 1.0 handles clusters, because as far as I remember, each tiny file on floppy disk occupied 1 Kb... which means 2 sectors per cluster. So on this basis, lets speculate that MSX-DOS 2.x can handle up to 64 sectors per clusters as MS-DOS can (and even lets dream that even 128 sectors (1000 bin) can be grouped but maybe it's used as a special flag value), and that the big total number of sectors value is stored on 4 bytes as with MS-DOS, we could have: FAT12: 128 Mb = 512 bytes * 2 ^ 12 * 64 (4 times bigger than actual limitation, still using FAT12 but it needs changes in boot sector for the number of sectors) FAT16: 2048 Mb = 512 bytes * 2 ^ 16 * 64 (about 4 millions sectors, which is the FAT16 limitation even on MS-DOS) I guess SCSI disks on MSX system use FAT12 with clusters of up to 16 sectors... Correct me if I'm wrong. If we avoid changing the number bits used in FAT, we also avoid all the major changes in the access method (assuming cluster are already used, without any limitation of bits above to 4 except the fact of the 2 bytes for total sectors number). Few years ago I tried to reduce the cluster size to 1 sector on a floppy disk to reduce the waste (many tiny files on the disk) but it failed. I tryed the same on RAMDISK, and it WORKED !!! so my hopes are great about playing with cluster size... So, what kind of modifications are needed for MSX-DOS in order to read big partitions? "Only" these, I think: 1) Change the method of knowing if the disk has a volume label. A good way is to read position #26 of the boot sector. MS-DOS 4 and higher stores the value #29 here as a DOS 4 ID flag, so I think we can use the same value or other for the same purpose. 2) When reading 0 as number of sectors, DOS must read the actual number of sectors in position #20-#23. 3) String at position #36 must be read for knowing the FAT type, and routines for handling 16 bit fat must be added. nihil if we can use the cluster
Back and Up...
Hi! | A|A (n n) \_/ I've been away from this list for a long time (due to personal problems that are not worth explaining). Anyway, I'm reading the old EMs (I'm about middle of January, now - yes, there is a lot yet to go...) But before discussing anything, I have a problem: someone said the third disk of "Aleste 2" at Funet is corrupted and asked me my version (I've finished it and it is okay). Unfortunately, I don't know who asked me it (I have an idea, but I must be sure before sending a 245KB long file through EM - which will become far larger when the system will get it into 6 bits). Oh, yes, he also asked for a working copy of "Vaxol". "Who are you?" Okay, that's enough about it. Hm... Ah, it is "Cyndi", not "Cindy", okay? Yes, a comprehensible error (I used to stumble at it, too). "Old fashioned superstitions..." I have F-1 Spirit CD. It comes with OGS (Original Game Sound) of both "F-1 Spirit" and "F-1 Spirit 3D Special". Personally, I found the "F-1 Spirit" musics far better than the "3D Special". More details about it can be found in my Page, which contains data of almost all of my CDs (there are a few not yet catalogued), including all my MSX and arcade albums. My Page is at "http://welcome.to/unicorndreams". Unfortunatelly, that album is not produced for a long time, now. Maybe people can find used disks, pirate copies or even MP3 (argh!) files of it... Older subject: someone asked "why not `segment registers'?" As far as I could read (it comes a point when you cannot bear the hard language anymore), no one answered to the question (they all just shout at the poor soul, "BECAUSE IT IS BAAAD...") I think I can answer better than that. Well, this is the last subject of this letter, so, if you already know why NOT to use segment registers, go to the next EM, because you should know, by now, that the answer is long. Take the popcorn (no salt for me...) A long time ago, in this same galaxy, IC production was expensive, because it was the state-of-the-art, experimental, pure art. It comes that one ought to economize transistors in its project if it wanted it to be "purchasable". Thus, the first CPUs were limited to small datum and address buses. As the hunger for memory grew with improvement of computer science (and computer geeks in their gadget-filled rooms), the CPUs got to have more lines in their address buses. New CPUs appeared every day as the technology made IC manufacturing cheaper (demand lowers prices, when you remove the politicians from the game). And each and every CPU was incompatible with any other one (even in the same IC "family"). One of the causes for incompatibility was that about the size of the buses. For example, an instruction that loads a byte from a direct address won't be the same in a CPU with address bus of 16 bits and another of 24 bits, like "Load A,(12CFH)" (16 bits) and "Load A,(0012CFH)" (24 bits - it requires 1 extra byte in the instruction to determine the address). There were many solutions for this specific problem. One, adopted by Motorola, was to build the CPU with larger internal buses, so it could be expanded externally if required (the 68000 family ever had a 32 bits internal structure, though the external buses could even be 8 bits). Intel solved the problem earlier, adopting the "segment registers". The segment register works exactly like the MegaROM or Memory Mapper in MSX, it selects which memory block will be accessible at a time. MSX has many memory segment registers, so several blocks can be made active at the same time. Intel CPUs have one for the executing program and another for the data they are accessing. They work like "mobile windows" to the program: it can only "see" (access) what is in front of a "window" (segment visibility range). It would be a wonderful feature if those registers could be set at any position and with any size, but, of course, that's not it. The designers didn't use the segment registers to expand an existing CPU, they used it to create a new CPU, one that didn't need a large and expensive internal bus (that is, they used segmentation to solve another problem, the price). So, a CPU that could only access, for example, 64KB, magically gained access to a multiple of that value, just like MSX with its memory expanders. To make the whole thing cheaper, they didn't allow the registers to be set at any position, but at 16 byte intervals (that is, the granularity is 16 bytes). In MSX MegaROM, the granularity may be 8KB or 16KB and in Memory Mapper, always 16KB. "All that!? So why complain about Intel's segmentation?" Because Intel's CPU was a new one, forged that bad to make it cheaper, incompatible with any other previous CPU. It was not necessity, like in MSX, but greed that brought it out of the sands. Of course, the "maxima culpa" falls upon those that adopted it as CPU of anything. "But still, what is the problem with segment registers?" Simple: no one puts
Connecting MSX and PC (solved)
As I promised , here is a working solution for connecting MSX and PC !
Try this Turbo Pascal code . 4 bits in 4 bits out via Joystick port and Pc
printer port . (Tested and works)
Sincerely Kari Lammassaari/Finland/ACDEMY
Oh shi.. The cable pinout lacks. Post it tomorrow !(I have to measure the
cable)
MSX-side :
-- cut here --
{MSX_PC.INC}
{Connecting MSX via joystick to PC parallel port }
{by Kari Lammassaari (ACADEMY) 1996-98 }
{The routines for PC are in file PC_MSX.PAS }
{REM IMPORTANT !!! In the block send/receive routines the two first
sent/received bytes contain the total lenght of the block including
the two first bytes (low byte first)}
{ This file contain following procedures and functions :
- Procedure JoyByteSend(value:Byte);
- Procedure JoyBlockSend(BuffAddr:Integer);
- Function JoyByteReceive:Byte;
- Procedure JoyBlockReceive(BufAddr:Integer);
and following type definition, which is used also in PC_MSX.PAS
}
Type DataBlockType = Record
Len:Integer;
ChkSum :Integer;
DataId :Byte;
Data :Array[0..255] Of Byte;
End;
Procedure JoyByteSend(value:Byte);
Begin
Inline($f3/
$3a/Value /
$67/$cb/$3c/$cb/$3c/$cb/$3c/$cb/$3c/ {High nibble to H }
$e6/$0f/ $6f/{Low nibble to L }
$3e/0/$d3/$99/$d9/$d9/$3e/$40/$d3/$99/$d9/$d9/$3a/Value /$d3/$98/
{The code above just writes current byte value on vram addr 0 }
$3e/$0e/$d3/$a0/$db/$a2/$cb/$47/$20/-6/ { Wait until ready ? }
$3e/$0f/$d3/$a0/ $7d /$f6/$50/ $d3/$a1/ { Send high nibble }
$3e/$0e/$d3/$a0/$db/$a2/$cb/$47/$28/-6/ {Wait until PC has
received }
$3e/$0f/$d3/$a0/$3e/$40 /$d3/$a1/{Reset data ready signal }
$3e/$0e/$d3/$a0/$db/$a2/$cb/$47/$20/-6/ {Wait until pc ready }
$3e/$0f/$d3/$a0/ $7c/ $f6/$50/ $d3/$a1/ {Send low nibble }
$3e/$0e/$d3/$a0/$db/$a2/$cb/$47/$28/-6/ {... }
$3e/$0f/$d3/$a0/$3e/$40 /$d3/$a1/
$fb);
End;
Procedure JoyBlockSend(BuffAddr:Integer);
Var BlockAddress :Integer;
Begin
BlockAddress := BuffAddr;
Inline
(
$F3/$DD/$2a/BlockAddress/$DD/$4E/$0/$DD/$46/$1/$DD/$7E/$0/$67/$CB/
$3C/$CB/$3C/$CB/$3C/$CB/$3C/$E6/$F/$6F/
$3E/$0/$D3/$99/$D9/$D9/$3E/$40/$D3/$99/$DD/$7E/$0/$D9/$D9/$D3/$98/
{The code above just writes current byte value on vram addr 0 }
$3E/$E/$D3/$A0/$DB/
$A2/$CB/$47/$20/$FA/$3E/$F/$D3/$A0/$7D/$F6/$50/$D3/$A1/$3E/$E/
$D3/$A0/$DB/$A2/$CB/$47/$28/$FA/$3E/$F/$D3/$A0/$3E/$40/$D3/$A1/
$3E/$E/$D3/$A0/$DB/$A2/$CB/$47/$20/$FA/$3E/$F/$D3/$A0/$7C/$F6/
$50/$D3/$A1/$3E/$E/$D3/$A0/$DB/$A2/$CB/$47/$28/$FA/$3E/$F/$D3/
$A0/$3E/$40/$D3/$A1/$DD/$23/$B/$78/$B1/$20/$8F/$FB
);
End;
Function JoyByteReceive:Byte;
Var Value :Byte;
Begin
Inline($f3/
$3e/$0f/$d3/$a0/ $3e /$5f/ $d3/$a1/
$3e/$0e/$d3/$a0/$db/$a2/$cb/$47/$20/-6/ {Pc data ready ? }
$3e/$0f/$d3/$a0/ $3e /$1f/ $d3/$a1/ {Set joy port 1 fo
reading }
$3e/$0e/$d3/$a0/$db/$a2/$e6/$0f/$6f /{Read and store data in L}
$3e/$0f/$d3/$a0/$3e/$4f /$d3/$a1/{Msx has read data }
$3e/$0e/$d3/$a0/$db/$a2/$cb/$47/$28/-6/
$3e/$0f/$d3/$a0/ $3e /$5f/ $d3/$a1/
$3e/$0e/$d3/$a0/$db/$a2/$cb/$47/$20/-6/ {Pc data ready ? }
$3e/$0f/$d3/$a0/ $3e /$1f/ $d3/$a1/ {Set joy port 1 fo
reading }
$3e/$0e/$d3/$a0/$db/$a2/
$cb/$27/$cb/$27/$cb/$27/$cb/$27/$67 /{Read and store data in H }
$3e/$0f/$d3/$a0/$3e/$4f /$d3/$a1/{Msx has read data }
$3e/$0e/$d3/$a0/$db/$a2/$cb/$47/$28/-6/
$7c/$85/$32/Value /
$3e/0/$d3/$99/$d9/$d9/$3e/$40/$d3/$99/$d9/$d9/$3a/Value /$d3/$98/
{The code above just writes current byte value on vram addr 0 }
$fb);
JoyByteReceive := Value;
End;
Procedure JoyBlockReceive(BufAddr:Integer);
Var Len,i :Integer;
Begin
Len := JoyByteReceive + 256*JoyByteReceive;
Mem[BufAddr] := Lo(Len);
Mem[BufAddr+1] := Hi(Len);
For i := 1 To Len+3 Do Mem[BufAddr+1+i] :=JoyByteReceive;
End;
- cut here ---
Pc-code
cut here ---
{PC_MSX:PAS by Kari Lammassaari 1996-98}
{The routines are to be used with the msx equivalent routines in
msx_pc.inc }
{REM IMPORTANT ! The block send/receive-routines expect the two first
received/sent byte contain the total lenght of the block including
those two first bytes !}
{This file contains following procedures and functions:
- Function ParallelByteReceive:Byte;
- Procedure ParallelBlockReceive(DataBlock:DataBlockType);
- Procedure ParallelByteSend(Value:Byte);
- Procedure ParallelBlockSend(Var DataBlock:DataBlockType);
and following type definition:
}
Type DataBlockType = Record
Len:Word;
DOS3 general setup
Hi, Time to talk about some of the general stuff, after this sector number discussion. How to build this new disk system roughly? Let me summarise some desires: -It should be able to use new devices easily, or it should be modified easily to support these -It should be able to have its behaviour adjusted in some ways by the user -It should support all current devices, and most current existing programs That makes a general setup quite clear: It should implement most of the available DOS calls and 'standard' system variables in a compatible way, in other words: implement most of these, where needed to keep things working. It should be set up in some modular way, so that for any change (FAT16 - FAT32, or some other file system), addition of new devices (PCMCIA cards, DVD players, etc. etc.) you wouldn't have to rewrite the entire system, but only certain parts. Most access to files/devices through DOS has to do with files. Direct I/O is only needed for a few applications which do lower level stuff like defragmentation, sector editing, disk checking etc. Many of these will have to be updated/rewritten to support new file systems anyway, so the only thing needed here, is to allow these programs to do their normal work for devices supported in the older system. So that, for example, a CHDSK writtten for DOS2 can also work with the new system, when it is run on a FAT12 device. For most programs, a higher level interface works fine, that only deals with drives and files in manner, where programs don't need to know how exactly it works physically. Here, you only need to know how to access these in a general way, and how to determine some characteristics of these, like random access or serial accessible, a read-only medium or writeable, fixed or removable, this sort of thing. In my view, most of the implementation of the DOS function calls should be implemented on this level, so that any single function can be used for all devices, which can be 'described' in these terms. You could do this by defining an internal 'file system interface', which allows access to whatever device, described in these terms (random access/serial, random access/write/read only, removable y/n etc.). A new device would then be easily added by writing a 'driver' that would implement this INTERNAL file system interface, without the need for rewriting any of the higher level software. ANY program implementing only this higher level interface would then automaticly directly work with this new device. And why not? Ofcourse, the system needs to be able to translate this into lower level stuff like file systems, partioning schemes etc. So, to keep this in a modular way, you might implement for instance a FAT12/FAT16 'driver', for controlling the most common hardware like floppy and harddisks, which would (in essence) do nothing more than implement this internal 'file system interface' on the one side, and use sector-I/O routines on the other side. This part of the system (which might turn out to be a big part) would NOT need to know ANYTHING about how the disk-I/O is done. So, this part should not mess with the low-level control of particular devices, it should only use general sector-I/O, and possibly some additional information also used for the file system, like whether a medium is removable or not. For instance such a FAT 'driver' part would only have any meaning for random access devices, which use sector-I/O. Devices which wouldn't allow access this way (like a network drive, routed through a serial or other connection, or a CD-ROM, which, if I'm right, simply doesn't have a FAT), would either be implemented on this higher 'file system interface' level, or accessed through another 'sub-driver'. These 'sub-drivers' would then either perform any I/O themselves (in whatever way they 'like'), or, for devices where it could be described in terms of sector-I/O, through a lowest-level interface, which would implement only that part. This would have the same advantage: If ANY new device could be used in a similar way by such a 'sub-driver' (like a FAT file system), all that would be needed, is an implementation of this lowest level sector-I/O interface, and if that would be done, everything possible with other sector-I/O devices would immediately work with this new device as well. I hear you all thinking: drivers, interfaces, would this mean a joining in with the mess you have on MS-DOS/Wintel (Windows/Intel) systems, with config.sys, memory drivers, separate driver files to be installed for every single device you can think of? Ofcourse not. One of the things I like about the MSX system, is its high level of 'plug and play'. My proposal therefore: Such a new file system would simply support all current devices for which the 'control method' is known, directly. For those devices supporting sector-I/O, it would either call whatever routines are available and/or
MSXlist site / Site da MSXList
Atencao, peco que nao apagues esse mail, mas primeiro leia-o e responda, se assim o desejar. Please, don't delete this mail, please read it first and reply if you want. [Portuguese] Como voce^ deve lembrar, ha' algum tempo atras o seu e-mail foi-me enviado para ser cadastrado na Lista de Usuarios MSX na Internet espalhados pelo mundo. A lista cresceu ao longo dos anos, e hoje temos mais de 380 nomes. Mas nao me sinto satisfeito, pois sei que muitos desses usuarios so' forneceram nome e e-mail mas nunca mais ouvi falar deles. Muitos tambem trocaram o seu e-mail e nao informaram a troca. Logo, creio que a maioria nao sao mais usuarios ativos. Entao, decidi fazer o primeiro grande "corta fora" da lista. Estou enviando essa mensagem para todos os usuarios cadastrados na lista, alem das listas de discussao conhecidas (MSX internacional, MSXBR-L e a Esquina das Listas) e do newsgroup comp.sys.msx, pedindo que se estiver interessado, tem um prazo de um mes para renovar o seu cadastro, senao sera' cortado da lista. Sabemos que a lista reduzira' em muito o seu tamanho, mas quero que apenas usuarios realmente interessados no padrao MSX estejam listados. Queria tambem lembrar que anualmente farei essa pratica do "corta fora". Logo, responda as perguntas abaixo e envie para o e-mail [EMAIL PROTECTED] (sem os sinais '' e ''). Passe essa mensagem para todos os usuarios de MSX que voce^ conhecer. Antecipadamente peco desculpas se voce^ esta' recebendo esse mail mais de uma vez, mas estou tentando cobrir todos os e-mails de usuarios MSX ao redor do mundo. Uma das minhas ideias e' poder oferecer em breve uma versao em HTML da lista, criar uma homepage da mesma, um cadastro com informacoes pessoais, etc. Se voce^ tem uma homepage que quer divulgar, um novo FTP site ou uma lista de discussao nova, envie um mail para [EMAIL PROTECTED] (por favor, sem '' e ''!) com a URL. Seus dados pessoais nao serao fornecidos para empresas ou nenhum outro meio de divulgacao interessado em fazer a detestavel pratica do spam-mail (a nao ser que seja uma empresa relacionada com MSX!). Ultimos comentarios: 1) Eu nao responderei nem receberei mails do cadastro nos meus e-mails pessoais, mas deletarei todos que forem enviados. Creio que fui bem claro nesse texto, afinal foi criado um e-mail especial justamente para evitar uma inundacao nas minhas caixas postais. Alem do mais, estou enviando esse texto atraves dele justamente para evitar que alguem de^ um reply e mande a mensagem para a minha caixa postal, nao para o e-mail da lista. 2) Se o e-mail a ser cadastrado nao for pessoal, mas de um grupo de usuarios, clube ou revista, por favor mencione isso nas observacoes. 3) Os FTP sites estao mantidos na lista, nao precisam ser recadastrados. Portanto, de^ uma olhada na ultima versao da lista para nao reenviar alguma URL que ja' esteja listada. As WWW homepages foram removidas, agora temos apenas o MSX Resource Center e o Baboo! 4) Por favor, nao me enviem nenhum mail perguntando alguma coisa sobre esse recadastramento, creio que esta' tudo bem claro para todos, ate' para um usuario idiota de Windows 95! Muito obrigado, desse modo voce^ esta' ajudando e muito o padrao MSX no mundo. Ricardo Jurczyk Pinheiro moderador da Lista de Usuarios MSX na Internet espalhados pelo mundo -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Perguntas: 1) Qual o seu nome? 2) Qual o seu e-mail? 3) Qual a versao do seu MSX (no caso de emulador, qual e rodando em que plataforma)? 4) Voce^ esta' em que pais? 5) Voce^ faz parte de algum grupo de usuarios, empresa ou entidade ligada ao padrao MSX? Se sim, qual o nome? 6) Voce^ tem homepage ligada ao MSX? Se sim, qual a URL? 7) Alguma observacao? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [English] As you must remember, some time ago your e-mail was sent to me to be added to the MSX Users List from all over the world. The list had grown up above the years and nowadays we have more than 380 names. But I'm not feeling well with the list, because a lot of these users had sent only his/her name and e-mail, but we haven't heard any more about him/her. There were many users who had lost or changed his/her e-mail, and haven't told to me this change. Well, I think that the majority of the list are not active users anymore. So, I started the first big "cut-off" on the list. I'm sending this message for all the people from the list telling that they should answer these questions which are below, in a one-month period. If you don't send in one month, your name will be deleted from the list. I'm sendind this mail to the known
Re: Bigger sector numbers
Hi again! Maarten ter Huurne [EMAIL PROTECTED] wrote: But you still haven't convinced me (and some others) why 4010 should be updated instead of creating a new routine at a new address. (...) By changing parameters of an existing call, like you suggested, programmers have to learn the changes as well. This is unavoidable. make every single piece of software that PERHAPS might still have some use, useless 'by definition', I can't think of any software, written for 16 bit sector numbers, that will function well on a partition requiring 32 bit sector numbers. Sure you can! -Debuggers with built-in sector-I/O function -Sector-editors -Disk TYPE checking utilities (=displaying bootsector-info) etc. etc. I WOULD agree, that for most of such utilities, their usefullness would be LIMITED for drives using big sector numbers. The only point I made here earlier: if you use an access method which remains compatible, you can still USE these. For a sector-editor, this would be limited to using it within a 16-bit sector number 'window', or the first 32 MB. of a bigger partition. But you can still USE that, to edit bootsector, FAT etc. If you use a new entry, the only thing you CAN be sure of, is that every existing software CANNOT be used for accessing those bigger partitions. Although some of you seem to like that, I think the problems that might occur when older programs are used for bigger partitions, could probably be overcome, or lived with. Like with the introduction of DOS2; many programs had to be 'hacked'/patched, things like MAP.COM/MAP.BIN were cooked up, but eventually, just about every existing program could be made to work under DOS2. When you use the existing entries, you can try and find such solutions, and use that software that still has some use somehow, but when you use new entries, you will simply have to rewrite every single piece of software to use the big partitions, and you will have as good as nothing to work on these in the mean while. That simply seems like a waste to me, and avoidable too. My view on this is simple: define new methods/entries etc., when there is a CLEAR ADVANTAGE to be had from this. If no such clear advantage exists, use existing entries/methods if possible, this will simply minimize the overall impact, and make acceptance easier. Advantages: - HD BIOS implementation doesn't have to check whether old (16-bit) or new (32-bit) calling convention is used. - Complete freedom in specifying parameters. I agree with these, however: -as shown earlier, the impact on performance is minimal for the total SIZE of code in a HD interface, it won't matter much either (checking 16/32 bit number, or using 2 entries instead) -freedom in specifying parameters? Nice, but as a 'programmer-minded-guy', I read that as: different sets of parameters to remember/look up, and 2 different addresses to call, depending on what disk/drive is accessed, for essentially the same action. You call that an advantage? I didn't hear anyone either, with ideas for extra/other parameters to use (other than a bigger sector number), so what would be left, is simply re-arranging the position of parameters in memory or Z80 registers. I don't see the use for that either; you might have done it differently when you had to define the original DISKIO now, but it is, and for me, this is okay as it is. Changing the behaviour of the DISKIO-routine (cache control, for instance) can easily be done using other ways, no need to re-define DISKIO itself for that. But there was a different suggestion that will work well to protect partitions: direct sector I/O must be enabled explicitly by the user. For example, by specifying a certain environment variable. You can do that, or disable partitions, or use environment settings to control this, but the one thing to note here, is that this is free (up) to the HDD-interface, to implement this somehow. This whole discussion was not about this. If you can hook up drives with bigger partitions to a HDD interface, and the interface would recognise it, it's free for the interface to give the user choices to disable/enable options on how to access these. The only thing this discussion really is about, is: IF a user would set the HD interface so, that programs would be allowed access to these bigger partitions, HOW to let these programs call this then? Wheter a particular HD interface will allow it, or what options the user has to control this, is simply up to the makers of such an interface. I think the pro's and con's on this issue should be clear to anyone by now. Can we please end the discussion on this part of the topic? It's not easy for the programmers of the HD BIOS. To fetch the sector number, the memory it is in must be selected. But by the time the HD BIOS looks up the sector number, a lot of slot switches have occured. Reading the correct values would take an inter-slot-read,
Re: DOS 1.40
Hi Everyone! I recently put a new disk in my MSX, and waited for it to boot. I was surprised to see that it booted MSX-DOS 1.40! I've never heard of this version before. Can anyone tell me what differences it has compared to other earlier DOS 1.xx-versions? Greetings, Diederick de Vries, Groningen (nl.) Hi Diederick. I have here a Dos Ver 4.00, but it hase a few new things in it: CLS Clears screen. VER Version number. BEEPBeep's. COLOR n n Color For/Back. INPUT xYou can Input 1 character. IF x ..You can Make the input do things. WAIT n Make the compure wait n seconds. I make a ,BAT file TEST.BAT to show you wat it can do! Grtz * TOM * TOMS BBS Online 00.00 -01.15 houre. Every day. 020- 6999263 Test.lzh
Old Stuff, Same Problems...
Hi! |
A|A
(n n)
\_/
I've read some interesting old EMs, about copyrights,
"copywrongs", copy-protections, hacking and so one... A friend
of mine bought PC's "Frontier - Elite II" (hey, people all
around, except for the graphics, MSX version is far better!) It
had a protection of the kind "type in the first letter of word X
in line Y at page Z". Well, I played the game in his house and it
locked me twice because I either counted the letters wrong (it
was not clear in the manual if I had or not to consider the
manual's page titles) or the manual was wrong (it was a new
edition and I don't doubt it or the game could have been modified
without the corresponding updating on the other part). My friend
was also locked a few times and after loosing a dozen games, we'd
got a game cracker in the Net and sent the copy-protection to
hell. Summarizing, I don't think any kind of protection is worth
the stress upon any single customer.
"So, software makers cannot protect themselves from piracy?"
Of course they can. A message like "unregistered software"
("software registered to XYZ" is even better) is a good start,
because "registered" machines (those in offices and legal
organizations) cannot use unregistered software, and there are
the "real money", not in the domestic user. Videogames are a
special problem, because the "main stream" is the domestic user.
The best protection against piracy, I think, is a good price
AND a good game AND a good distribution: if the price is high,
it will be worth for the pirate to copy the software and the
manual; if the game is not good it won't seem worth to the user
to buy it; if the game is hard to find or to purchase, most
users will take the easiest way of piracy (for example, it was
absurdly hard to buy original Konami MSX software in Brazil,
because of high custom taxes and mailing costs). Small
softhouses cannot afford a big distribution plan. Small Famicom
and Super Famicom soft makers used to sell their products to
bigger enterprises, like Nintendo of America and Japan Enix.
Compile, from which we got so many wonders like Aleste and
Golvellius, was a small softhouse and could afford direct
distribution only in Japan and for "open systems", like MSX
and other Japanese machines. Super Famicom's "Super Aleste"
was released by Japan Toho (the original studio of Gojira
[Godzilla]). What I mean from all this is that it would be good
if home programmers and small softhouses could join to make
a really wide distribution net. There are surely good ideas
and programmers around. Buying large packs of diskettes and
printing many manuals at once would lower costs. A non-profit
organization would provide what's necessary to stop piracy.
Joining enough people to raise such project is difficult.
If the joy of having a program running in an extinct machine
ten years from now is not enough for someone, then move to
a "probably" long living plataform (I'm now programming in
JavaScript, which fortunately has almost nothing to do with
Java, it's more like HTML with IF-THEN-ELSE built-in). MSX has
a lot to give, still, and it's enough for me to have fun out of
it (that's why I only make freeware and public domain for MSX).
If it enjoys someone else, then it is an even better payment.
David Bradden, one of the programmers of "Elite", has released a
Famicom version, just for fun (it is a freeware and can be found
in the Net). Famicom don't have a block definition VRAM, so it
should be impossible to make vector graphics in it, but it has a
small RAM for block positioning and programmable video pointers.
He made the block positioning index point to ROM and the block
definition to the RAM, that is, something no one has thought
about before, and made the game. I wonder how many things about
MSX no one has thought about before. How many of them would be
worth purchasing as a game...?
Games also present another problem, easily noticable even in
this list: I HATE "3D Wolfenstein" and clones, some people love
them. I love shoot'em ups, while others simply prefer to die
than to play "Aleste". Though I don't like "battle modes", I
prefer them to the pretense real-time battles of "Dune II" and
similars, and others just cannot deal with pop-up combat menus
(they are easily beaten even by slimes). MSX users are very
ecletic in their likes and dislikes, from the classics of the
Colecovision convertions to the CRPGs of Microcabin. How to sell
a hundred copies of any program to such an audience? Maybe a
wonderfully programmed multi-style game, in which the player
could select the kind of "game style" it prefers... But it would
be too complex and expensive to be programmed. It would be a fun
to play "Episode II - Gopher no Yabou" ("Nemesis 3") in CRPG or
C-adventure style! It would be like pressing F2 and making
"Majou Densetsu" ("Knightmare") become "The Maze of Galious" or
F3 and play it as "Shalom" (Konami prefered to release them as
three independent games, of course). How
RE: Audio-CD, Volume 3...
Hi Mari, Here you are some of my musics. You will realise that I am a coder and not a musician XD Regards, Manuel Galious.pma Galious2.pma Katrin.pma Sacra.pma Viento.pma Walking.pma Yenes.pma
Robotz 0.2
Hello all, I hereby send version 0.2 of the ROBOTZ specification into the MSX world. The arithmatic and logical/bit operations are still to be filled out, but I've elaborated the rest of the document, embedded some suggestions and other comments (thanks, Maarten :-)) and introduced META's (my own comments on what I've written). Hope you like it... Eric Ah, almost forgot: happy new year 2 you all :-) robotz.txt
Dit kan ik jullie niet onthouden...
Dit stukje komt uit de Vrij Nederland, die het op zijn beurt weer uit de Provinciale Zeeuwse Courant heeft. Laat iemand anders het maar aan de niet-Nederlanders uitleggen... ~Grauw Scan1.jpg
Re: Partition table format
Hi all, I ditched up some info on partition/disk formats used on PC systems, I found it in a program called HelpPC, in the DOS collection on SimTel download site. It seems a bit old (dated 1991 or so), but I have a feeling this was checked with/compiled from info on many systems, and might be a good reference. I attached the info on partition tables, bootsector FAT info to this mail, hope you will get it okay... I suggest you put such info from different sources side by side, and make some comparisons, maybe that will clear up some points which aren't quite clear. Anyway, the best way to determine how to make this distinction in parttitions disk types, I think would be to read out exact bootsector-info, and maybe some of the first or last data sectors/FAT elements, from as many actual disks you can find, like: MSX formatted disk (SS) " " " (DS) " " " (SS/DS, formatted with DOS2) MSX-formatted HD disk? PC 720k format PC 1.44M format If you have a PC: your own harddrive (and maybe 2nd or 3rd) maybe the same on some of your friend's PC's hint: forget about MSX HD's, you might check'm, but I have a feeling the way many of these are partitioned, is incompatible with other systems, using some home-built format... Put that side by side, and that should make it pretty clear how such bootsectors, partition tables etc. are actually used/filled in with current systems. BTW: on formatting a disk, I think it would be best to fill in every field in the bootsector that you know the meaning of, when you can fill it some meaningfull way. Regardless of wheter you think it's used or not. (You know Murphy; if you don't, it'll give trouble some place) Fields that are not really clear: give 'm the same values they have on other systems; if these are different, give 'm the most commonly used value, or make 'm 0, etc. Some interesting things: -According to this info, cluster numbers FF0h (FAT12) and FFF0h (FAT16) can be used, only FF1h resp. FFF1h and higher have special meaning. I thought someone mentioned earlier, that FF0h resp. FFF0h had this special meaning (bad cluster), which doesn't match this info. -What does this 'number of hidden/reserved sectors' in the bootsector (word at offset 1Ch) stand for? If I'm not mistaken, this normally reads 0001h, and I suspect this might be the number of sectors before the FAT(s). So, normally 1 (1 bootsector), but if different, this would mean: bootsector, some more 'reserved/hidden sectors', FAT, etc. But is that actually true? Does anyone have some good info on that? -In relation to this: what exactly is the number of the 1st data sector? You might think: number of FATs x sectors per FAT + directory sectors (#entries/16) + 1 bootsector. Looking at the above, it might also be: number of FATs x sectors per FAT + directory sectors + number of reserved sectors. As these are normally 1, it wouldn't differ, but if this field is 1, what would be the right calculation method then? -Isn't it so that clusters 0 1 are normally not used (FAT entries for this filled with media descriptor and FFh's), and that the first data sector(s) corresponds with cluster #2? How is this for FAT16? I think generally, the best way to determine the disk format, is to check first whether it is a valid bootsektor. Like check if 1st byte=EBor E9h, maybe check some other things, and if correct, try to determine the actual format from the bootsector parameters. (and use calculated number of clusters to separate between FAT12/FAT16, as Nestor suggested). If this fails, take 1st byte (media descriptor) of sector 1 (which should be assumed to be the 1st FAT sector then), and see if you can match that with some known disk format. I would do this only as a last resort, the media descriptor alone is rather unreliable, as it's used very differently across systems. For instance: F8: SS disk on MSX, harddisk on PC. F9: double sided disk (720k) on MSX, used for several different types of disk on PC. F0: would be 'illegal' (at least I haven't seen any 'official' definition of this one anywhere), but I've seen it used for RAMdisks, MSX HD's, etc. If all fails: 'unsupported disk type' Then there's something else to note: You all talk of FAT12 - FAT16, like there's nothing else. Ofcourse these 2 are most common I'd say, but there's also FAT32 (Win95), HPFS (High Performance Filing System, used with OS/2?), NTFS (Windows NT file system), etc. etc. (different formats for Unix as well?). Ofcourse you can't handle all these file systems, but it would be usefull to know exactly what defines a FAT12 or FAT16 disk, and what might be some other format. If you only say, oh: no FAT12 - FAT16, you might screw up badly a disk if it was formatted with FAT32 or some other system. As before, you don't have to be able to handle it, but it's sure usefull to be able to spot it. Jon De Schrijder [EMAIL
Merry Christmas.... and...
Hello, XSW-Magazine sends it's Christmas Greetinx to eveybody all over the world... When Santa visits, there aren't always presents you get --[ MARI ]-- -- Visit XSW-Magazine's HomePage at: http://www.xsw-msx.demon.nl -- M.H.M. van den Broek Molenweg 17 5342 TA Oss The Netherlands +31 (412) 630653 / +31 (622) 125592 -- Kerstman.jpg
No Subject
I found an old disk in which I putted the work I started about this idea (10-11 years ago ...) Give a look ! I had forgotten this disk and now it's here back ! It seems that it doesn't work so well, I don't remember the stage of development in which I was doing this. Try to understand code ... and be patient ... I was not a so good programmer in those time ... not a lot of comments ... caos ... Bye, Stefano PS this mail was sent to all the ones interested in my idea ... :-) --- Fronteddu Stefano [EMAIL PROTECTED] [EMAIL PROTECTED] http://space.tin.it/computer/stfront MSX, Sardinia, Robotics, Friends http://computer.digiland.it/1461 MSX Soft Tips Page ICQ: 21401454 0338/3645458 robotwar.zip
Re: New Flash Complex Algorithms
My remark "New Flash == Slow RAM" isn't about internal technology, but only to suggest that Flash can be as easy to use as SRAM for nonvolatile storage. My point is that "complex" algorithms aren't needed for all Flash devices. Simple deblocking routines can make the page-mode transparent to applications, and make use of Flash burst-mode transfers. Flash does have the drawback of slower writes, and a limited lifetime of write-cycles. There is also a advantage when using Flash memory instead of S-RAM. Flash memory doesn't use external components to keep the contents when you turn off you computer. About the limited lifetime : I don't think this is very bad at all... How many writes are done under normal conditions in one year??? A game : let's say 1000??? (for savegames only) Settings for some programs : 30 times in a year??? H What was the subject that resulted into these Flash memory topics??? Greetings from Erik Maas p.s. At the time I only know one released project that uses normal Flash memory (29F???) and that's an IDE interface from Sunrise Swiss. Very nice for a software updates... At the time it was released, the software contained a lot of 'undocumented features' (bugs). I wonder if the software is mature now, still haven't tried anything with it. MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Bigger sector numbers
For all clarity: you're talking about msxdos.sys(0005)/f37d. That also has to be changed. Nevertheless also our diskroms need modification (even when intercepting #f252, unless you make another patch for each interface :-( ) and that was the thing we were talking about. Sorry because I always say same, but: look at MSXCDEX for MegaSCSI!! It uses this method (own code in a RAM segment and #F252 patching) and works fine! Only problem is that it works only with MegaSCSI. And why not to make a patch for each interface? Or a drivers system as I proposed. Then there is no need of modifying DOS kernel ROM (it is quite dangerous I think, and unuseful for people having DOS2 in ROM). Does everyone agree on the fact of using 24bit sectornumbers instead of 32? It is so simple as this: FAT16 -- Maximum partition size = 2Gb -- 24 bit sector numbers is enough. People speaking about FAT32: please don't build your house beginning by the roof. Let's make a reliable FAT16 driver, then let's talk about FAT32 if we really need it. Besides MegaSCSI is prepared for handle 24 bit sector numbers, and NOT 32 bit sector numbers. I don't know about other interfaces. By the way, does anyone know EXTACTLY what does ROM code and what does RAM code of DOS 2? (RAM code surely is a copy of part of the ROM code, right?) - Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user http://www.geocities.com/SiliconValley/Bay/9797/msx.htm [EMAIL PROTECTED]ICQ#: 18281450 "In Windows 98, 3.000 found failures of W95 have been corrected..." Translation: 3.000.000 not found failures continue without being corrected... - MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: jpg-format
At 02:41 PM 11/11/98 +0100, shevek wrote: :Hi, : :As I mentioned before, I want to make a jpeg-viewer for gfx 9000. :But it is really hard to find the used compression method. If anyone :knows the method or has some source code (any language) of a decoder or :encoder? Anything is welcome. : Try http://www.wotsit.org/graphics.htm for JPEG and other (graphic) file formats Marco === Marco F.E.J. Frissen Philips Digital Video Systems email: [EMAIL PROTECTED] tel: +31 40 27 32 479 www: http://www.broadcast.philips.com The opinions expressed are mine... Mine! All Mine! Minemineminemineminemine! MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Evolution of MSX
Hi Official MSX3 is impossible until ASCII gives up the copyright. I think ASCII does not make next MSX. I do not want wait for ASCII. And as a one user who dreams new generation of MSX... The problem is only the fund. I want to give a serious question. "If I make new MSX, will you buy one?" Some years old. Russian users did can not to buy any computers. And they build at home ZX SPECTRUM. I think SPECTRUMs users in russia was more that msx in all other world. :-) For this question, someones say, "If it is fully compatible to MSX1,2,2+ and TR ...". Others say, "If it has very high performance...", etc, etc. I think if it has very high performance. What I can take from MSX1,2,2+,TR ? It is very old system. If msx3 will be fast. It can to have emulation mode. But It will be like MSX1,2,... easy vs PC. Of course, I know there are still many users who want new MSX regardless to the condition. But not enough... If one million MSX users promise that they will buy one, I can make new MSX until this year... why not? Yeh.. it's a joke. But very serious... I want to make it If I will be the MSX3 users ALON ;-) Bye Valery MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
RE: MSX 3D games
At 15:34 24/08/98 +0200, you wrote: Have you heared about "THE WRECK"? It's much better than Episode 4, buch since I have lost the manual, I can't play it at all! Does anyone have "THE WRECK"'s manual? I don't think that making a 3D game for MSX would be a good idea... This discussion started due to Final Fantasy VII, which is a very good game. But, this (and RE2) are the only 3D games I like. But, technically it is possible to make a 3D game on MSX. I say this because I have seen DOOM on a... Spectrum!!! Yes, it is true. And if a Spectrum can run DOOM, then a MSX can create virtual reality!!! Well, it's funny, but Specrum has Prince of Persia, Mortal Kombat, Street Fighter 1 and 2! And I saw a Spectrum version of Xybots (do you remember this game) which was much better than the MSX version. The Speccy version had shadows, a lot of colors, etc. But of course, if MSX-Xybots were MSX 2 or above... Bye Speccy! Ricardo Jurczyk Pinheiro (\__/) Star Trek, X-Files, M. Sc in Numerical Modelling (..) _) Comics, MSX, Anime, Universidade Federal Fluminense/\/\ (Gospel Christian __ .___ _ _(m__m)_)_ _ \__ \| |\_ ___ \ / _ \ \__ \ \__ \ \_ \ | _/| |/\ \/ / /_\ \ | _/ || \ / | \ || \| |\ \/|\|| \ |` \/|\ ||_ /|___| \/\|/||_ //___ /\___ / \/ [EMAIL PROTECTED] - http://pagina.de/rjp \/ \/ \/ "Freedom is the right of all sentient beings." - Optimus Prime Say NO to Internet censorship! Say NO to monopolies! Say NO to Microsoft! And, why not... Say YES to Jesus Christ?! MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Large partition support
If everything is ok, will add FAT16 to DOS2 kernel soon. If you do this, I'll put your name to my first son!! X-) About the method for reading and writing 32 bit sectors, if we can't use shadow registers nor index registers we can forgot from now on the idea of patching the existing function, right? There is no place for specifying drive letter, number of sectors, and a 32-bit first sector number with just A, BC, DE and HL! When I proposed this way I forgot this detail, and I don't though that PC has larger registers. Then, maybe best solution is to create a new system call, for example with parameters: A = Drive letter B = Number of sectors to read or write DE-HL = First sector number Cy = 0 for read, 1 for write (or, create one function for read and other for write, just as current MSX-DOS) ...and release old function calls available for 16 bit sector access. - Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user http://www.geocities.com/SiliconValley/Bay/9797/msx.htm [EMAIL PROTECTED]ICQ#: 18281450 "In Windows 98, 3.000 found failures of W95 have been corrected..." Translation: 3.000.000 not found failures continue without being corrected... - MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Please update your links/bookmarks!
Hi! As you may know, Manuel Bilderbeek's pages are on an illegal (but not _that_ illegal) server. This server addres is http://studs.sci.kun.nl:. Since a few weeks my pages can also be reached via a legal server on my university. THe files are exactly the same, but now you can use the legal official server. So please people, use the legal server for the following pages (all, except The Ultimate MSX FAQ, which URL is http://www.faq.msxnet.org): 1. Manuel Bilderbeek's Homepage: http://www.sci.kun.nl/marie/home/manuelbi 2. Manuel Bilderbeek's MSX page: http://www.sci.kun.nl/marie/home/manuelbi/msx.html 3. Manuel Bilderbeek's Bookmarks: http://www.sci.kun.nl/marie/home/manuelbi/bookmarks.html (and there are more, but those are merely subpages) ad 1.: My homebase, with the What's New section of my pages (Check it out to see what's new! If I don't forget to update this list, you'll see I make lots of updates!), a menu, and personal stuff. ad 2.: MSX Activities, news, Turbo Pascal stuff, my MSX collection, wanted, for sale (check it out), some software and a menu ad 3.: Contains a very good up-to-date linklist with almost all MSX pages on it, split in useful categories. So, I hope you all change your links and bookmarks to my pages and I also hope to welcome you there! Note that the old server will still be online, but its working is not guaranteed. I don't know how long it will work, so therefore I'm asking you this favour. Thanks in advance! -- Grtjs, Manuel PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org) PPS: Visit my homepage at http://www.sci.kun.nl/marie/home/manuelbi MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Turbo R?
Hey! Tell me what you mean with "clever programming", could come in very handy. ==Share it==. Anyway, I think you're too pessimistic. I think they HAVE enough money and I don't think $250 is too much for such a miraculous chip. I mean, compare it to the prices in the 'old times'!!! Anyway... ~Grauw -Oorspronkelijk bericht- Van: Tristan [EMAIL PROTECTED] Aan: [EMAIL PROTECTED] [EMAIL PROTECTED] Datum: woensdag 17 juni 1998 23:48 Onderwerp: Re: Turbo R? I think this wait has to be implented in all new hardware. They do it too on the PC, so why not on the MSX? I mean, They could have foreseen it, because there are already 3 different MoonSound-drivers. That can be solved by clever programming. However, I already have some moonsound magazines/musicdisks that simply crash if runned on 7MHz, so probably there's not very much clever programmers out there. By the way. I have been reading this thread, and got the impression some of you actually think those vaporware projects will get finished *and* produced in some quantity at a reasonable price. For that to happen one needs lots of cash. So far, only Sunrise Swiss has proven to be able to do such things. Have a look at current hardware available: eg. GFX9000 is very expensive (dfl. 500/$250), has only a few users/programmers and because of that almost no software support. Tristan + Omega + join #msx on undernet + [EMAIL PROTECTED] + | | FUNET MSX maintainer | ftp://ftp.funet.fi/pub/msx | + irc: OmegaMSX +Techno composer+ http://users.bart.nl/~omegamsx + MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Yamaha FM Synthesizer chips...
At 14:04 29/10/98 +0100, you wrote: At 01:27 PM 10/26/98 +0100, you wrote: NYYRIKKI wrote: Isn't there a JPG file viewer for MSX? Yes there are few, thank god. I'm just suprised, that nobody has done one for GFX9000. (This is a tip for someone) Ok, I can do that. If someone can tell me about the JPG-format, that is. (this is a question for someone) U can find JPEG specifications in ftp://x2.ouli.fi. Doesn't work. Are you sure it's the right address? Oooops! ftp://x2.oulu.fi, not ouli. Sorry! _ __ | __ \ (_| ICQ UIN: 3635907 | | M. Sc. In Numerical Modelling - UFF | |__) | _ __ _ _ __ __| | ___ Niteroi - RJ - BR +-+ | _ / | |/ __// _` | '__/ _` |/ _ \ | Sola Scriptura | | | \ \ | | (__| (_| | | | (_| | (_) | | Sola Gratia | |_| \_\|_|\___\\__,_|_| \__,_|\___/ Jurczyk Pinheiro |Sola Fide| http://pagina.de/rjp - [EMAIL PROTECTED] - [EMAIL PROTECTED] | Solo Christi | MSX freak, X-Phile, Trekker, Christian, Transformers, | Soli Deo Gloria | Anime (Yamato!), CuD, Linux, Rock, Comics, and hate M$! +-+ MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: PC-Age...
Jacco Bot wrote: cancelled the development of this program, mainly because I've lost all the source because of a harddisk crash. Why this is so common probblem ? :-( Do you have even MSX sources ? However, I'm currently busy with Age98. Same program but slightly different (better?). It is able to read most image formats, .SC5 .SC7 .SC8 .S12 .JPG .GIF .BMP .TGA .RLE .DIB .PCX. It is capable of saving to the following formats, .SC8 .S12 .JPG .BMP but this will be extended. It can convert any 24-bit color image to a screen 12 image with optimisation routines for color spill reduction. The program also allows retouching of pictures as well as the basic drawing, lines, circles, (pattern) fills, blending of images, gray scale transform, and more. Age98 runs in Windows95, is written in Delphi combined with assembly. When we can expect MSX version :-) That would be so cool, but I allready can quess right ansfer... It would be too slow, too less users etc. etc. Anyway very very nice, that it can support directly also MSX screen modes. MSX-AGE is my most used drawing proggram. and then comes Philips Video Graphics. BTW does anybody have a version of VG for DOS2, that could save also 7 first bytes to HDD ? This is a hobby project of mine, if anyone is interested I will upload it to funet, if not my feelings are not hurt, =) I bet, that there are really plenty of people, that are interested. BTW does it work also in Win NT? (Sorry about non MSX question.) ,_. _=_=_=_=!_MSX_!=_=_=_=_=_=_=_=_, ! A1ST ~--- - I ( o o o o o o )i /`, / .::;::; ., / :::.:.:.::::!. -=- `, ~== NYYRIKKI : [EMAIL PROTECTED] ICQ:24863850 www.clinet.fi/~nyke MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: SCSI as a MSX link ?
:Hello : :I wouldn't call it easier, if I were you... :By the way, I think I was wrong, it has to be hold key 5 to :give ID 5 and :hold key 6 to give ID 6... You can't give the interface ID :7, if I remember :the manual well (I have never tried). : : :Manual? Did you say manual? Where is that manual or do you :refer to the readme on disk? A real one, got it together with BERT... But the BERT is sooo sloow Get a Novaxis for speed. And installing a SCSI harddisk is'nt that difficult that you will need a manual for it... :Btw: does your way save the info in the clockchip or do you :have to hold the key each time you reboot? :Using SCSID you can do ID-switching with software by setting :the proper ID, reset and let your software go on It does not save it in the clockchip, for then I had to re-press it every reboot... My batteries are down, so the info isn't stored. Nope, Novaxis saves in the clockchip, but BERT saves it happily into a byte of flash-rom or SRAM or whatever it is called, I don't know. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Bigger sector numbers
At 03:47 PM 11/24/98 +, you wrote: I proposed earlier to use for both BIOS-routine 0144h and diskROM-entry 4010h the following change, to allow the use of bigger sector numbers: But you still haven't convinced me (and some others) why 4010 should be updated instead of creating a new routine at a new address. This would insure 100% compatibility, have a negligable impact on performance, and easy to use for programmers. It's not easy for the programmers of the HD BIOS. To fetch the sector number, the memory it is in must be selected. But by the time the HD BIOS looks up the sector number, a lot of slot switches have occured. Reading the correct values would take an inter-slot-read, which is slow. For the BIOS/diskROM entries, it would pose a problem to define new entries; where to place such a new entry? #4034 and beyond, plenty of space left. How to pass the extra info? What "extra" info? Because those would be new calls, you would have complete freedom in choosing any way of passing parameters. If called with A=2 (get info on FAT16 support): returns: A=0: no FAT16 support A0: FAT16 supported Any extra info to be determined later, if necessary More useful would be a call that tells you which filesystem is used on a particular drive. Imagine a system with both a FAT12 and a FAT16 partition active. Knowing that FAT16 is supported is not enough, you have to know on which drives. To make this more general: you want to ask which filesystem is used on a certain drive. Only thing left then, would be finding a way for the system, to determine if a driver supports 32-bit sector number I/O, or not. I suggest using one of the existing diskROM-entries (preferably one of those besides 4010h), with some special input value, to determine this. I suggest using a "magic number" identification. A short number or string that is specific for 32-bit sector number compatible device driver ROMs. Just like "OPLL" is used for FM-PAC. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Sony HB-F900 and Sony HB-T600
Not every pic on FUNet is ripped! On FUNet are dozens and dozens of pics now. I know. With 'the ones on Funet' I meant only the ones of the HB-F900! But still, almost a third of the pic's are from my site. Are you sure? At the moment 201 hardwarepictures are online on FUNet! And there are still more to come... Maybe you should update your Banzai page Patriek? Haven't seen an update in ages. Maybe you should visit more often, I just updated 2 weeks ago! (August 1st) Sorry, I just went on holidays that day and missed your message... I saw the updates. If you like to help us with the MSX hardware-pictures database, please upload your new pictures! The format is as follows: (mention the CAPS) Producer_Type-number_Short-description.jpg (Short description optional) e.g: Sony_HBD-30W_diskdrive.jpg Sony_HBD-30W_diskdrive_2.jpg (another picture of the same item, look what's online to see what number you should use) National_CF-2000.jpg Panasonic_FM-PAC.jpg Daewoo_DPC-100.jpg etc. Note that not all files are named correctly on FUNet. But it would be nice that all new pictures are in this format. By the way, you gave me permission to use your pics for The Ultimate MSX FAQ. Thanks again for that. And to compensate the 'ripping': you can link to the pics on FUNet if you like. I know I gave you permission and I appreciate you giving proper credit in TUMF! (TUMF?! ;) Ok. About linking to the FUNet pics, I think (especially for my site) that a webbased origin is better than ftp. Besides, I have plenty of space with my ISP (10 MB) and plenty of bandwidth too (1GB/month) so :) Ok. Then you can e.g. download them. But linking is working fine in case of The MSX Hardware List, for example. Grtjs, Manuel PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org) PPS: Visit my homepage at http://www.sci.kun.nl/marie/home/manuelbi MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Robotz 0.2
shevek wrote: On Wed, 6 Jan 1999 [EMAIL PROTECTED] wrote: The ATCK command makes the robot attack another robot at a neighbouring square. What if there is no robot in that square? Is the empty square attacked or is there no attack at all? Since attacking costs a turn, there is a difference. IMHO, the empty square should be attacked, regardless of whether the square is actually occupied or not and it takes a turn. Question is whether you will lose energy attacking an empty square... I'd say it would result in dropping the energy on the square, so you can pick it up afterward. This would imply the DROP command becomes obsolete. The DROP command can drop a variable amount of energy. An invalid attack costs a fixed amount of energy. Right? No, both drop and atck have as a parameter the amount of energie to use. This is the amount you lose. Attacking an empty square would cost you energie. My idea is to drop this energie on the neighboring square. This is, IMHO, a good thing. (simlicity) Simplicity is not the same as compactness. By "misusing" constructs to eliminate others, the design does not become simpler. This is true, but here I think (since you cannot drop on a robot and you cannot attack an empty square) this is not a problem. If at some point in time I want to write two robots who can co-operate it who be nice if robot A could drop energy on B. Kind of a recharge for the other one. David Heremans -- "How should I know if it works? That's what beta testers are for. I only coded it." (Attributed to Linus Torvalds, somewhere in a posting) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Joycom/Joynet... fixed game
Hi, Last week I uploaded a game for testing your cables. But the game was with still with a bug. Sorry for that. Today I uploaded a new fixed version. The game was saved in ASCII text format with SAVE"snafu.txt",A Just browse the URL, save the form like text and then LOAD it into your MSXes. Some useful information: - The game cannot be played in a single MSX. You will need at least two MSXes linked by the Joycom cable to see it running. - Our communication routines have a delay, which was calculated for 3.58 Mhz clock MSXes. So probably it won't work in faster MSXes. The interrupt frequency doesn't matter. - The game doesn't autodetect in which port the cable is set. You MUST set the joycom cable in port 2 of each MSX computer linked. - The game doesn't count how many computers are in the ring. So at the start of the game you must type how many computers are in the ring. - The game doesn't assign a number to each computer in the ring. You must type what is the number of each MSX, according to the sequence of the links. If you have two computers linked, just enter 1 and 2. But if you have three or more, you must respect this sequence: 1 sends to 2, and 2 sends to 3, and 3 sends to 1. And so on. - If you lost the conection, the game hangs. Then you can hold ESC key to skip the communication routines and press CTRL-STOP to return to BASIC. This is also the only one way to end the game without turning off the computers. - There is still a bug in the game, because you will see that when two heads are in the same pixel, the collision is not detected. - We will continue to improve the game. We tested it last saturday with 3 computers, but we can actually test any communication routine with up to 5 MSXes (one MSX2+ with 1Mb and four MSX1 with 64Kb). If you want our help, just mail me. Joycom cable schematics URL: http://www.geocities.com/SiliconValley/Lab/2328/msxframe.html Our game URL: http://www.geocities.com/SiliconValley/Way/8461/joy.txt Thanks Werner Kai MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: JPEG file format
About JPEG, Is JPEG that good? It seems beaut for photos, but I've saved files in JPG of geometric designs (Flags, plain colours, sharp edges), but when opening the file later it seemed like a bad analogue TV reception! -- with ghosting of the line edges, and colour washing. You would think compressing of plain geometric shapes, of say only 5 colours total, would be easy. I tried saving with maximum quality (LView Pro, PC), but that made no difference. Whats going on here? GIF seemed to compress just as well but with no errors. Plus it decompresses faster. As stated before, JPEG is meant for photographs! In those pictures real sharp well-defined edges are not so important. I believe JPEG is a Fourier-transformation of the original picture. Therefore: lots of CPU time to (de)compress it, you lose some of the original bitmap information. But the advantages: the compression rate is very high, and for photographs the loss of information is not detectable. By the way, the JPEG viewer for MSX (JLD.COM) is not perfect... The colours are very strange sometimes... So I recommend to use JPG only for 8 bit photographs, where it was made for. (So, not really useful for V9938, but maybe for screen 8 pics it is useful) Grtjs, Manuel PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org) PPS: Visit my homepage at http://www.sci.kun.nl/marie/home/manuelbi MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joystick network program working
Jeroen Smael wrote: :Hi Laurents '~Grauw' Holts, Ja hoor, FutureDisk-humor... : If any MSX sends a byte all other MSX-computers connected to this : network recieve it, is that correct? : :Yes, this is indeed correct. :Sending of a message can only be initiated by the MSX that holds the :bus token. The message travels all around the network and returns to :the bus master (the MSX that holds the bus token). This MSX removes :the message from the network. If the message travels all the way round :the network the master is assured from the fact that the receiver has :received the message (otherwise he could not have relayed it to the :next MSX in the ring). But this means that every byte recieved has to be sent through to the other computers exept for the sender. This is already twice as slow. Plus that an additional ID-byte/nibble has to be sent to indicate from which computer the byte is sent. This also means a delay which makes it twice as slow. So, all this together means that when you are using a network with more than two MSX-computers connected, the speed will be 4x slower than when you're just connecting 2 MSX-computers. Not to mention the delay between the sender and the last computer in the ring. Right now, I'm programming a source to let 2 computers communicate (data has to be sent by blocks, not by byte). It will be quite fast but it hasn't got an option for more than 2 MSX-computers. Maybe later. But... are more than 2 computers so useful? I mean, TRIPLEX was big fun, but most people won't have more than 2 computers and most games (that's what I think this thingie is going to be used for mainly) won't work with more than 2 players. At least not my game. By the way, in a game like triplex the speed can be much faster, for the data can be put just in a nibble, and the other nibble can be the ID (max. 16 computers...). ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
My MSX project
Hi
I wrote I want build MSX-3 ( non ASCII standart )
I wrote FPGA-Mem memory controller for my MSX3 computer. It take
EPM7128SLC84. I writing other FPGA-IO now.
FPGA-Mem specification:
Using one or two 16Mbit 60-nc DRAM 1MbX16Bits
Z380 Memory map
00-00MSX MEMORY
01-3FDRAM (2MB x 16Bit)
40-7FEXTENDED MSX SLOT 0
80-BFEXTENDED MSX SLOT2
C0-FFINTERNAL MSX SLOT ( FOR FLASH ROM DISK)
MSX MEMORY
-0003ROM-BIOS -- for invalid opcode exeption
0004-3FFF CS0
4000-7FFF CS1
8000-BFFF CS2
C000- CS3
CS[0..3] tru via port A8 mapper. Y can using mapper for acces
00-3F DRAM
SLOT [A8] MAP control FLASH ROM 128KB
SLT0 CS0 BIOS
SLT0 CS1BASIC
SLT1 CS0XBIOS
SLT1 CS1BDOS
SLT2 CS1DOS2 ( 64KB controll 4104H )
SLT3 CS[0..3] MAPPER DRAMM ACCES
I want place into the FPGA-Mem MEMORY and I/O acces-NMI trapper.
Other FPGA will has EPP , SLOTS ARBITR, I/O decoder for VDP, IDE, 85C30
serial, CMOS, AY and KBD .
KBD controller will use Z8 microcontroller for PC-KBD to MSX-KBD and
MS-mouse to MSX-mouse convertions.
Extended MSX slot it is my last problemm. We want compatibility. And We can
take 62pins ISA connector. Get out 51,52 pins and insert wall.
1 2
| |
| |
| |
| | 49,50
wall
| | 53,54 Extended MSX
| |
| | 61,62
Extended MSX must has,
A[16..23],D[8..15],/BLEN,/BHEN,/IORD,/IOWR,/MRD,/MWR,/MSIZE,/BREQ,/BACK (It
is 25 pins) .But Extended part has 10 pins. MSX slot has two-spare , /rfsh
... it is all. May be We can use SW1,SW2,-12, +12, sound in e.t.c
We can take PCI or PCMCIA conector or make PCMCIA slot. I do not know yet.
We did want make PCI slot but It will hi-cost.
Bye
Valery
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
AW: Stop this babbling!
-- Van: Anne de Raad[SMTP:[EMAIL PROTECTED]] Verzonden:vrijdag 15 januari 1999 11:28 Aan: [EMAIL PROTECTED] Onderwerp:Re: Stop this babbling! And I mean you: Anne and Robert! Stop this polutting of the mailingslist! Go and twaddle using your own email accounts; not [EMAIL PROTECTED] Nobody is interested in this nonsense talk of yours. Bye, /\/\ark Eh. This is what MSX is about. Having fun together. If you don't like it, don't read it. There is a DELETE button on your keyboard. Greetings Robert, Hideo and YUM I agree completely with Robert, this is just what MSX makes all the fun, at least, it was the reason I loved MSX for over the past 14 years. Just having a blast with fellow MSX-nerds!! And by the way, we DO say interesting things When you followed our discussion, you have learned Hideo Kojima is the man behind Metal Gear Solid, a great PSX-game. He also made the original versions on MSX. Another character, Masahiro Ikariko, is the most brilliant musiccomposer ever lived.. He made all the music for the MSX Konami-classics as Solid Snake, (SD) Snatcher and many, many more. Be glad this mailinglist gets messages. When I log into a commodore or pc newsgroup, it takes me hours to download all the messages and that's just great fun..The more messages, the more activity... I really don't get it. We want the MSX-world to stay alive, and when we have such a 'discussion', people start pissing and say we have to be serious... Downloading this messages really don't cost that much time... But okay, we'll stop and with pain in my hart, I say goodbye to my closest friend Robert 'Hideo' Vroemisse-Kojima YUM... MSXstill4EVER!! Anne de Raad Anne, het leven is niet mooi, maar jij kunt haar een beetje mooier kleuren (Herman van Veen (kinderlokker van beroep)) Thanks for your support. You deserve a beer at Tilburg!! Bye Robert, Hideo and YUM MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joystick uitgang
At 17:16 14/02/98 +, you wrote: Weet een van jullie of je van de joystick ingang ook een uitgang kan maken, zodat je dingen kan besturen via de joystick uitgangen... It is possible to send data through the joysticks-port. But unfortunately it is very limited. There is only one pin which can be used for this purpose. I can't recall which one it was but I can look it up... I've been taking a look into some old MSX Magazines (1989!), and I saw 2 FS-W1SX (MSX 2+ from Panasonic, externally very similar to Turbo-R) linked by the 2nd joystick port of each computer, and playing F1-Spirit 3D Special. I think that in Sean Young's homepage you can find all the steps to prepare this cable. And there is an even older game where we can play by link: F-16, from ASCII (1986). Amazing! Ricardo Jurczyk Pinheiro (\__/) Star Trek, X-Files, M. Sc in Numerical Modelling (..) _) Comics, MSX, Anime, Universidade Federal Fluminense/\/\ (Gospel Christian __ .___ _ _(m__m)_)_ _ \__ \| |\_ ___ \ / _ \ \__ \ \__ \ \_ \ | _/| |/\ \/ / /_\ \ | _/ || \ / | \ || \| |\ \/|\|| \ |` \/|\ ||_ /|___| \/\|/||_ //___ /\___ / \/ [EMAIL PROTECTED] \/ \/ \/ [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/9822/ - ICQ UIN: 3635907 "Freedom is the right of all sentient beings." - Optimus Prime Say NO to Internet censorship! Say NO to monopolies! Say NO to Microsoft! And, why not... Say YES to Jesus Christ?! MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: IDE driver documentation
On Sat, 7 Nov 1998, Egor Voznessenski wrote: I _DO_ have complete, working DOS1 DISKROM source code, I even did huge modifications to it to make it more suitable for HDD interfaceing (eg FAT is not held in memory but is loaded from disk when necessary). I even located and corrected a bug of the original code (it is probably present in ALL diskroms out there, but luckily it needs a very special configuration to show up) There have been few quys, who have been telling about bugs in MSX ROM. (This bug, MSX tR disk drive shutdown bug, MSX1 paint routine bug etc.) I think, that it would be nice, if we could collect this information together somewhere with descriptions about actions, when this bug appears, where is the probblem and how this routine should be done. It is very anonying, when you do some proggram, that does not work and after months you find out, that a probblem was in ROM routines, that you used. About this source code... Can you upload it to funet or can you put it to your www-page? There seems to be many people, who wants it. BTW does anybody have assemby source for working paint routine ? ,_. _=_=_=_=!_MSX_!=_=_=_=_=_=_=_=_, ! A1ST ~--- - I ( o o o o o o )i /`, / .::;::; ., / :::.:.:.::::!. -=- `, ~== NYYRIKKI : [EMAIL PROTECTED] MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
ZAPP-virus...
Hello, I seems that there's still somebody spreading the ZAPP-virus... So everybody has to have UNZAPP or TVAC in case of infection with this virus... --[ MARI ]-- -- Visit XSW-Magazine's HomePage at: http://www.xsw-msx.demon.nl -- M.H.M. van den Broek Molenweg 17 5342 TA Oss The Netherlands +31 (412) 630653 / +31 (622) 125592 -- Tcav.com
Re: Joystick uitgang
On Sat, 14 Feb 1998, Kari Juhani Lammassaari wrote: At 05:16 PM 2/14/98 +, you wrote: Weet een van jullie of je van de joystick ingang ook een uitgang kan maken, zodat je dingen kan besturen via de joystick uitgangen... It is possible to send data through the joysticks-port. But unfortunately it is very limited. There is only one pin which can be used for this purpose. I can't recall which one it was but I can look it up... Im Happy to inform that You can use max 6 bit's for output and 6 bits for input using PSG ports 14 and 15. I've connected PCprinterport and MSX joystickport and it's working OK. (The MsxLaplink is still uncomplete.. I'll find time for that project ) The code for both machines is TurboPascal + ML. If You need further information, let me know. Sincerely Kari Lammassaari Hello Kari, This is something I and a lot of people I know have been waiting for. I would be great if we could use such a device to transfer files between the pc and msx. Like the interface I had to transfer files between the pc and my snes. A lot of new applications for the MSX can then be make, like a terminal server where the msx can be a graphical terminal client. Or, and this is an idee that I and Jacco of Jinnovation (formerly know as JBsoft) has been walking with for a long time: to make a MSX multiplayer game. The plan was to connect two to four MSX machines to a PC through such an interface. The pc then act as the server for the game and calculates all the data needed for the MSX machines who are clients of that pc. Game data like the position of the players in a level etc. etc. The only thing you need is this interface, the software and a few more parallel ports on the pc. (you can buy parallel port boards with 2 extra ports for a few bucks) I'm sure he'll make the pc portion of the interface software if this project is going to continue. Jacco has knowledge of ML, turbopascal and delphi, amoung other languages. Let me know what you think of it, greetings, Sander MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
RE: Prince of Persia
Castlevania for PSX is excelent, in my opinion, the best of all Castlevanias. I've heard much great things about the PSX Castlevania. As soon as I have a PSX (They recently dropped price!) I'll put it on the top of my want-list ;) (well, right behind Metal Gear Solid at least :) And I think that is possible to make a MSX game of a similar quality. It's amazing what you can do on MSX if you set yourself to it! (and know HOW ofcourse) Ofcourse there are only idea's now, why wouldn't that be "serious"? I mean... It's no fun to COPY (or port) another castlevania to MSX. What would be nicer is to make a NEW version, and preferably BETTER. I am not saying that. I suggest that would be better a sequel of the"true" Castlevania, instead of a "parody". Create a new story, using the characters of the Belmont family, and things like that. Aha. Personally, I wouldn't mess with the Belmont family. First, because Konami has apparently figured out a complete timeline from the beginning of time 'till the very end and a new game thought up by us (or anybody else) wouldn't fit. My ideas for a parody are great (so I have been told), but ofcourse the game itself should be very serious. (It's just the scenario that's crazy) The title would be something like SDSDFD, although I'm not sure about the SD (SuperDeform) part ;) Well, if you wouldn't have the first problem, you could solve the second! ;) But it's true... Our former programmer had to quit because of his studies :( he he he... and when they finish their studies, it comes the job, the marriage (...), sons, ... argh! I feel ... old! ;-) Yeah... life sucks sometimes doesn't it? ;) Greetz, Patriek [EMAIL PROTECTED] .-. ,. ,-. TNI on the web: | '-.| ,-. \ '-' http://www.xs4all.nl/~newimage/ Member of| .-'| | | | ,-. The New Image | '--' | | '-' | Check out "MSX Banzai!" at: since 1991`--' '-' http://www.xs4all.nl/~newimage/MSXBanzai!/ MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Joystick network program working
Hi all! This is a combined reply... ] And what about the auto detect option? I asked a couple of days ago, but ] there was no reaction, so I'll ask again: ] Would it be a good idea to connect TRG_A to RIGHT? Using this, we could ] make an "auto detect" option: the program would be able to see in which ] joystick port the network connector is plugged in. This means we need another additional wire? Why not, with DIN5 we do have enough connections available to make it work. What I mean is connecting TRG_A to RIGHT inside the DB9 connector. A simple feedback loop. It doesn't require an extra wire in the cable. The idea is that an MSX toggles TRG_A a couple of times and then reads RIGHT to see if it reports exactly the same state (0/1). If it does, a joystick network device is connected to that port. These signals are also sent across the network, but if we make the protocol such that every transfer starts with a signal from TRG_B, this is not a problem. By the way, I haven't seen any posting from Maarten ter Huurne lately. Has he dropped out ;-), have his MSXs blown a fuse (due to no ground connection) :-(, or is he just waiting to see what connection he must use? Two reasons: - I was working on some projects for my study (to the Dutch readers: heb nog een paar studiepuntjes nodig) - TUE popserver was down this weekend But I'm still on the project! Or keep the MSX-es electrically separated alltogether and use opto-couplers to transmit the signals from MSX to MSX, like it is done in MIDI. It's less cheap of course, but chances for short-circuiting etc. are reduced to zero! I think a device with opto-couplers is compatible with one that uses direct connections. I mean, using opto-couplers doesn't change anything other than making it safer. So anyone could decide for himself whether to use opto-couplers or not. Am I right? Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Info needed.
On Fri, 6 Feb 1998, NYYRIKKI wrote: Does anybody have info about PHYDIO routine? I know, what I must input to that routine, and what AF and B should contain, when it exits, but is there something, that I don't know? I'm trying to make disk-drive emulator for Novaxis SCSI system, and it is working quite a good under Disk Basic version 1.0 so that I can load cracked megarom games etc. but DOS1 is not working good. Sometimes it generates diskerrors, and when I try to load any proggram it hangs. Maybe there is also something in HD-reading routines, that will modify something important in system ram, but I don't know. I have used physical I/O routine from HD interface, so it should be accessed as close hardware as possibble. I also patched PHYDIO just after jump to #4010 If anybody has any good ideas, please help. I'm really stucked. Ok, you can use the PHYDIO routine in the following way: HL=memory address where data will be read or written DE=starting sector from disk, beginning from zero B=number of sectors to be transfered C=type of disk: FC=40 tracks single sided disk FD=40 tracks double sided disk F8=80 tracks single sided disk F9=80 tracks double sided disk A=number of drive (0=A, 1=B, 2=C, 3=D) there's no drive default if CARRY FLAG is reset, sectors will be read if CARRY FLAG is set, sectors will be written After load these registers with the desired values, you can call the PHYDIO routine through addresses 0144h or FFA7h. I think that if you modify the contents of the hook FFA7h, you can create your emulator. The exit code of the PHYDIO routine is CARRY FLAG and register A. If carry flag is reset, the operation was successfully completed. Else, register A will have an error code. I don't know the error codes, but if you do some tests, you can easily detect the write-protection detected code. If you were using physical I/O, could you say me how do you do this using a memory address-based disk-interface? That's all! Marco Antonio [EMAIL PROTECTED] MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: CD ROM aan Novaxis
Use MSXCDEX! for novaxis you have to type: MSXCDEX -gscsi With this driver you can use it with normal dos-commands like dir and copy. pmext won´t work. The problem with lots of these programms is that they want to open a file for reading and writing which is not possible. copy and xcopy and multi mente work perfectly... greetings Maico Arts MSX-NBNO I have a Club Gouda SCSI controller with Novaxis ROM in my Turbo R with a 200Mb harddisk. I experienced problems with fdisken of a ZIP disk. In the end I succeeded with de NFDISK programm. (It bugged with some sort of dump data in de top of the screen as soon as I insert a partition and also while writing the partitions, but after several times pressing space it worked) Is there a better programm for partitioning? The original FDISK programm that was with the NOVAXIS didn't work, or I do it wrong. The partitions gave "Error reading disk" errors while doing DIR. I created the partitions and after Writing partition data I Initialized them from the main menu of FDISK. Another problem I have with trying to access one of the CDROMs that came with the last issue of MCCM. I tried to use the CDROM utils from Henrik Gilvad from 1994. (CDDIR3.BAS, CDIR.COM, etc.) But these doesn't seem to work on NOVAXIS. What utilities should I use? (and where to get them?) --- - --- Groeten en tot Mailens Hans-Peter Zeedijk, Systeembeheer, [EMAIL PROTECTED] Deltion College, unit GDW Nijverheidsstraat 1, 8031 DZ Zwolle Tel: 038-4545600, fax: 038-4547421 --- - --- MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: ZIP on MSX
At 08:04 04/07/98 +0200, you wrote: At 23:02 03/07/98 +0200, you wrote: Grauw, you didn't read: I wrote about the INTERNAL SCSI ZIP! That one has jumpers for all SCSI ID's and termination. You are right about zip together with HD, because if you only use ZIP, you have to reboot when you want to change ZIP's. I have (in a 8250) a Seagate Another good thing about Mega-SCSI is that you don't need to reboot your MSX when you change the Zip disk. Just exchange it, even if it's the only SCSI device. On megascsi I think all your partitions are the same size (except maybe for the last one), and all start at the same point. This would mean when you change disks you always get the same partitiontable. Not really, you can creates partitions of any size, up to 32 Mb. You have to take care ofcourse that you have command.com on the first partition. Or in the A: drive (Mega-SCSI RAMdisk). Bye! Ricardo Jurczyk Pinheiro (\__/) Star Trek, X-Files, M. Sc in Numerical Modelling (..) _) Comics, MSX, Anime, Universidade Federal Fluminense/\/\ (Gospel Christian __ .___ _ _(m__m)_)_ _ \__ \| |\_ ___ \ / _ \ \__ \ \__ \ \_ \ | _/| |/\ \/ / /_\ \ | _/ || \ / | \ || \| |\ \/|\|| \ |` \/|\ ||_ /|___| \/\|/||_ //___ /\___ / \/ [EMAIL PROTECTED] \/ \/ \/ [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/9822/ - ICQ UIN: 3635907 "Freedom is the right of all sentient beings." - Optimus Prime Say NO to Internet censorship! Say NO to monopolies! Say NO to Microsoft! And, why not... Say YES to Jesus Christ?! MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Anti-virus
I know of 2 different ones, so you don't have to wite any. I think one was called Techno Crew AntiVirus (TCAV), I forgot the name of the other one. Mail me if you want any of these. It is called UNZAPP So if you ran into that Zapp-virus, please do me a favor, and send it to me (Zipped/Arj/Lzh-ed disk-image of an infected disk, or files would be fine). I don't have it, but I hope, that you are not going to do some learning in virus makeing purposes. I think, that it is easy to look at that virus and notice, that you could make a much better one... Don't do it ! I once had a good idea how to make a virus, that could modify it self each time when it infects a file so badly, that it would have been almoust unpossibble to detect or remove it from infected files or atleast in reasonabble time... Anyway I kept that idea ONLY as a idea, because I know, that it would have been very challenching, but I don't like to have viruses on MSX. originally, or if there are any other virusses or alike on MSX? Yes, some Russian Michailo wrote one some time ago, but if I'm correct he had some little accident with it and after that he destroyed it by him self without publick release... (I hope) ,_. _=_=_=_=!_MSX_!=_=_=_=_=_=_=_=_, ! A1ST ~--- - I ( o o o o o o )i /`, / .::;::; ., / :::.:.:.::::!. -=- `, ~== NYYRIKKI : [EMAIL PROTECTED] MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Wanted:
I am looking for the the folowing original games: Atletic Land and Magical Tree both from Konami. Thanx in advance. Raymond Visit my MSX-page at: http://www.tip.nl/users/r.hoogerdijk
Re: New product
Hello Erik, Can you tell me if it is possible to use very fast modems with this 232 interface. Specify very fast... 33k6 works, at least there are people using it. I use CACIS program but sometimes it is very difficult to use all Internet services, I will like to know more about ERIX program. Thanks in advance. When I connect to my PC localy, 115200 baud is not a problem. The hardware handshaking makes sure the buffer doesn't get full. (controlled by software) I have to confess 115200 baud works better on a turbo-R, that means : it can handle the data much faster. But a 3.58 Mzh Z80 can do it too, although not fast. You see that RTS will be more inactive then. I don't really know how good Erix will handle the internet services you are using. Cursor keys can emulate MSX, VT-52, ANSI and PC. (Cursor key codes when using the default settings in Telix). This is the data the MSX sends. Colour ANSI is also supported. Ah!, do you know who can repair my Novaxis interface?, but not Arjan Prosman, he sent me back my interface again broken. Regards. ALBERTO As far as I have heard, the 33C93 isn't made anymore. There are newer versions, but they are not pin compatible. I "HAD" a SMD 33C93A on a PCB, but I have trown it away a week ago. I will see if it is still there. (probably not) Greetings from Erik Maas MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Important!
This is a small list of hoax - false viruses alarms made in mails, mailing lists, or usenet, only to block some internet servers... DO NOT BELIEVE that stupid warning message, nor the "make fast money", "make a wish or your computer will crash" Thank you! MetalGear "Magnetic Airline Trays" Internet Hoax (06 Jan 98) "AOL Cookie" Internet Hoax (03 Nov 97) "Returned or Unable to Deliver" Virus Hoax (20 Aug 97) "Join The Crew" Virus Hoax (13 Jun 97) "AOL4FREE" Internet Hoax (07 Apr 97) "Matra R-440 Crotale Virus" Hoax (07 Apr 97) "YUKON3U.mp JPG Virus" Hoax (07 Apr 97) "Jessica Mydek" Internet Hoax (06 Mar 97) "Naughty Robot" Internet Hoax (05 Feb 97) "Kidney Harvest" Internet Hoax (05 Feb 97) "ActiveX" Virus Hoax (18 Dec 96) "Penpal Greetings" Virus Hoax (11 Dec 96) "Deeyenda" Virus Hoax (27 Nov 96) "Ghost" Trojan Horse Program (20 Nov 96) "Irina" Virus Hoax (06 Nov 96) "Good Times" Virus Hoax (26 Oct 95) -Message d'origine- De : Remco van der Zon [EMAIL PROTECTED] À : [EMAIL PROTECTED] [EMAIL PROTECTED] Date : vendredi 30 janvier 1998 13:41 Objet : Important! Hi Everyone, If you receive an email entitled "JOIN THE CREW" DO NOT open it. It will erase everything on your hard drive. Forward this letter out to as many people as you can. This is a new, very malicious virus and not many people know about it. This information was announced earlier this week from IBM; please share it with everyone that might access the Internet. Once again, pass this along to EVERYONE in your address book so that this may be stopped. Also, do not open or even look at any mail that says "RETURNED OR UNABLE TO DELIVERY". This virus will attach itself to your computer components and render them useless. Immediately delete any mail items that say this. AOL has said that this is a very dangerous virus and that there is NO remedy for it at this time. Please practice cautionary measures and forward this to all your online friends ASAP. Greetings, R. MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Evolution of MSX
Hi, all I want to build MSX3. But I think, MSX2 has very bad memory manager Mapper. If I use Z380 the mapper is not need. But DOS2 using mapper and I will have a problem porting software. Secont VDP is stopped since. I can build 9990 using FPGA but ... The problem compatibilities is too. The MSX2 slot is old. It has no DMA or large adress bus. It is bad. You can see SNES. It has 8 chanels DMA. I don't think at all that the memory mapper is a problem. You can build a memory mapper compatible to MSX2 and you can run DOS2 softwares on you new machine, say MSX3. Also you can build huge memory for 4G linear address space of Z380. And new softwares based on MSX3 can use the linear address. I think that we need a standard in the memory structure for MSX3. One method is to build a switch for changing the memory structure. And other method is to use address decoding. For example, memory mapper when the address is below 64KB, and linear address when 64KB. We can build vdp compatibilite with SNES. And can to write full speed emulator. Flex10K can reconfigure many times. It has internal config RAM ! VDP is a problem really. I don't know V9958/V9990 is available now. But I think Flex10K is very expensive and not fast enough. I'm currently using 10K50. It is very hard (seems to be impossible) to obtain 30MHz performance when logics become complex. VDP is very complex... I hope that Yamaha produces VDPs... Or we force him to produce...? I have idea MSX3 can hase PCI. Can you explain more details? - Jun. MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
