Re: Enschede
Hi all,
I happen to live in Enschede, and am fortunate to say that I have not yet
heard of anyone I know, to be badly hurt or worse.
On the other hand, I know many people here, and this makes this explosion feel
very nearby...
My own home is about 1,5-2 km. away from were it was - everything fine here though.
A woman I lived with for about a half year at my previous address (about 1 km. away)
saw the blast from Glanerbrug (8 km. away), a window in her house was damaged.
In the 'muziekcentrum' ('music centre') here a block of concrete fell on the
roof (1 km. from the blast!) - no-one hurt there.
Some colleages at work were away - 1 helped his parents, whose home was badly
damaged, another had all here windows blown out.
The friend of a house-mate of mine just got away, but saw his house being destroyed.
2 Ex-housemates (I live in a sort of student-house with some 10 people) lost their
home because of the blast, etc. etc.
I hope not, but it would not surprise me if this 'personal list' is not
complete yet ;-((
I think the number of people who died is about to be adjusted upwards; with
some 400 homes destroyed, and +/- 1000 badly damaged, I don't believe only
some 20 people were killed. We'll see
Thank you for your interest...
Alwin Henseler([EMAIL PROTECTED])
from Enschede, the Netherlands
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED]
and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in
the body (not the subject) of the message.
Problems? contact [EMAIL PROTECTED]
More information on MSX can be found in the following places:
The MSX faq: http://www.faq.msxnet.org/
The MSX newsgroup: comp.sys.msx
The MSX IRC channel: #MSX on Undernet
Re: YM2413 datasheets on the net (was: Just a curiosity)
Airam Rguez. <[EMAIL PROTECTED]> wrote: >in the web page of yamaha, sound section of LSI components appears: > >YM2413 --- OPLL -- Sound generator blah blah blah MSX2 Compatible ;) > >Regards > >Airam > >PS: this link is http://www.yamaha.com/lsi/index.htm YM2413 = FM-PAC/K (MSX Music) sound generating IC. Yamaha has had a PDF document on this IC on their site for some time already. I have some printed document myself, titled "YM2413 Application Manual" (a scan of this is somewhere on Funet FTP site, I believe). I compared these a while ago, and they match for the most part. A small bit of programmer's info is missing in the Yamaha document (hey, it's a datasheet), for the rest the info is exactly the same. And the Yamaha document is much more nicely formatted. So if you're a FM-PAC/K programmer, emulator builder or so and you don't have this info yet, I suggest you get it from the Yamaha site ASAP. 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 "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in the body (not the subject) of the message. Problems? contact [EMAIL PROTECTED] More information on MSX can be found in the following places: The MSX faq: http://www.faq.msxnet.org/ The MSX newsgroup: comp.sys.msx The MSX IRC channel: #MSX on Undernet
Re: Expanding RAM on the music module
Hi..! Roel de Wit <[EMAIL PROTECTED]> wrote: >I'm looking for information on how to expand the RAM on my Music Module (I >want to run unknown reality correctly). Can somebody please help me with >this ? For this, check out: http://huizen.dds.nl/~alwinh/msx/hardware/audio256.htm It shows the connections for both 32 KB and 256 KB. sampleRAM to the MSX-Audio chip, with description. Pin numbers for the Philips Music Module are indicated, and as shown, has been used & tested. Greets, 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 "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in the body (not the subject) of the message. Problems? contact [EMAIL PROTECTED] More information on MSX can be found in the following places: The MSX faq: http://www.faq.msxnet.org/ The MSX newsgroup: comp.sys.msx The MSX IRC channel: #MSX on Undernet
Re: 7MHz with normal sound???
Hi you all,
Laurens Holst <[EMAIL PROTECTED]> wrote:
>I was wondering... When my MSX works at 7MHz, the sound gets all garbled up.
>So now the rest of the motherboard (and the cartridges) get the 7MHz clock
>signal. Is it possible to 'block' this signal and relay the old clock signal
>(if the chrystal is still there?) to the rest of the motherboard???
>
>I don't think this can harm (turboR does the same, doesn't it? Only the
>processor needs the higher clock frequency), and it would be great to
>finally get rid of the sound-problems with for example PSG, SCC, FM-PAC,
>MSX-Audio (one of my MSX-Audio devices already has got its own chrystal).
This is possible, but depends on the following:
In MSX machines I know, the standard 3.58 MHz. clock signal is used for 2
purposes:
-CPU clock,
-and as base frequency for audio generating IC's.
The CPU clock signal is often used to control the signal timings of
DRAM memory in the machine. And here is the issue:
If these funtions are seperate (read: in seperate IC's), then you can simply
'feed' 3.58 MHz. to the audio parts, and the, possibly 7 MHz., CPU clock to
the Z80 and DRAM controlling IC('s?).
But if this is all controlled by one central IC ('MSX-engine'), then you can't
seperate these funtions. If you would feed it the old 3.58 MHz. signal, then
the DRAM timing would have no relation anymore with the CPU clock.
-> DRAM wouldn't work -> well, you get the idea...
This setup (one big IC) is used in MANY machines.
Exceptions are possible here as well:
You could add your own logic for generating the DRAM control signals, or
you could use SRAM instead
In short: it all depends on your particular machine, and what you're willing
to change.
Greetings,
Alwin Henseler ([EMAIL PROTECTED])
http://huizen.dds.nl/~alwinh/msxMSX Tech Doc page
(not updated in a looonnng time, but several goodies are still there ;-))
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED]
and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in
the body (not the subject) of the message.
Problems? contact [EMAIL PROTECTED]
More information on MSX can be found in the following places:
The MSX faq: http://www.faq.msxnet.org/
The MSX newsgroup: comp.sys.msx
The MSX IRC channel: #MSX on Undernet
Re: Z380, PMA, Compass
Hi all, Nestor Soriano >[EMAIL PROTECTED]> wrote: >I had though for example on a fast PMA extractor but I haven't the PMA >format specifications. Maarten gave me the sources of a PMA extractor for >UNIX, but it's very hard to trace it and discover how the specifications >actually are... (^^!) > >So here is my question: does someone have the PMA format specifications, or >know where can I found it? Please, just plain specifications if possible, >no sources. And by the way, also for ZIP and LHA if you have any. 8-) Maybe there don't even exist such a thing as 'specs' for the PMA format, only programs that use the method - who knows? But check out UNPMA.COM, on my page: http://huizen.dds.nl/~alwinh/msx/software MSX Tech Doc page software section It contains full (Z80 assembly) sources of a fast PMA extractor (comments in the source are in Dutch though). It doesn't give PMA format 'specs', but using it you can fairly easily find out how PMA files are organized. And for the compression method: although I rewrote lots of the code (reverse engineered from PMext), I don't even fully understand the method used. Anyway, maybe this helps... Greetings, Alwin Henseler ([EMAIL PROTECTED]) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in the body (not the subject) of the message. Problems? contact [EMAIL PROTECTED] More information on MSX can be found in the following places: The MSX faq: http://www.faq.msxnet.org/ The MSX newsgroup: comp.sys.msx The MSX IRC channel: #MSX on Undernet
Re: Re: New fairs are added!!
Hi all, Manuel Bilderbeek <[EMAIL PROTECTED]> wrote: > Het woord 'stand' bestaat niet in het Engels, dat heet 'booth' (Translated: the word "stand" doesn't exist in english) Wrong... a dictionary I have here gives as some possible translations for the english word "stand", when used as a noun (dutch: zelfstandig naamwoord): -statief (stander, standaard) -stopplaats (halte, voor een bus bv.) -tribune -kraam, kraampje (wat hier bedoeld werd, betekenis klopte dus wel) -rek (wijnrek bijv.) And there's also many possible uses of this word as a verb (Dutch: werkwoord) or as an adjective (Dutch: bijvoeglijk naamword) Just so that you know it Greets, Alwin Henseler ([EMAIL PROTECTED]) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in the body (not the subject) of the message. Problems? contact [EMAIL PROTECTED] More information on MSX can be found in the following places: The MSX faq: http://www.faq.msxnet.org/ The MSX newsgroup: comp.sys.msx The MSX IRC channel: #MSX on Undernet
Re: F1 Spirit
Hi, Frederik Boelens<[EMAIL PROTECTED]> wrote: >2) As some of you already know, we're busy making a sequel to >f1 spirit, but we still haven't found a good name for it. >(f1 spirit 2 is not a good name I think) >So if you have a nice suggestion, please mail!! > how about 'F2 Spirit' ? Greetings, Alwin Henseler ([EMAIL PROTECTED]) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in the body (not the subject) of the message. Problems? contact [EMAIL PROTECTED] More information on MSX can be found in the following places: The MSX faq: http://www.faq.msxnet.org/ The MSX newsgroup: comp.sys.msx The MSX IRC channel: #MSX on Undernet
Re: 1.44 MB. disks?
Marco Antonio Simon dal Poz <[EMAIL PROTECTED]> wrote: > > The 2793 floppycontroller HAS the capacity to handle 500 Kbit/s > > (apparantly, this was used for larger 8 inch disks -a lnnngg, > > lnnngg, time ago). > > Are you SURE??? If WD2793 has this capacity, then let's do a big research! Texas Instruments TMS 2793 (is the same FDC) datasheets say so (no doubt), and I don't think they lie. The 2793 works with a 'bit clock' that is a combination of some quartz input frequency (mostly 1 or 2, and can be 4 MHz.), and both hardware- and software-settable dividers. Like 2 MHz. divided by 8 -> 250 Kbits/sec. Resulting bit clocks are mentioned of 125, 250 (DD disks) AND 500 (8" and HD disks) KHz., or Kbits/sec, if you wish. > [...Z80 clockcycle counts...] > > Did you verify a clockcycles table for this instructions? They're a bit > different from my values. A bit different? You mean: 1 clocktick different..!! I did some research once, timing duration of 3.58 million times repeated instruction sequences (with interrupts disabled, every clockcycle taken then gives exactly 1 second delay), and timing this with a hand-stopwatch. Primitive, but solid. One rule became clear, of which I have never found an exception yet: Clockcycles taken by the Z80 in a MSX are the same as is stated in Z80 datasheets (I used Zilog's), PLUS ONE. So Zilog docs say NOP = 4 cycles -> on MSX: 5 cycles Zilog docs say instruction = xx cycles -> on MSX: xx+1 cycles The same applies to conditional JP, CALLs & RET's: Zilog says DJNZ = 8 or 13 cycles (8 if skipped, 13 if jumping) -> on MSX: 9 if skipped, or 14 if jumping This behaviour matches perfectly MSX definition: Z80 CPU, with 1 wait state in M1 (machine cycle one). In other words: normal Z80 timing, with every intruction taking 1 clockcycle extra. Ofcourse same timings apply for Turbo-R in Z80 mode. > > -Do the INI in the above loop for starters (!): increases pointers, > > AND sets flags! > > I didn't understand. Could you explain what do you mean? According to Zilog docs, the INI instruction DOES change flags. How exactly, I don't know. It's kind a like with the IN F,(C) instruction, Zilog says: affects flags (and it does), but doesn't say how. I only suggested that maybe you could use this effect. Maybe you can find a description of the exact behaviour on Sean Young's pages (http://www.msxnet.org). 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: Mapperports
TED]> suggested: > What if someone writes a mapper support driver for DOS1? > Shouldn't be too hard. Programs could even install such a driver > themselves so that they can switch the mapper using a single > interface. That would be perfect! I think that DOS2 and its mapper support are essentially 2 separate things. Although I'm not sure if DOS2 itself could work without its built-in mapper support. But the other way round: why not? You might even include this in a add-on ROM, so that a non-DOS2 using machine could have mapper support, right after power-on. Or: modify a DOS2 ROM, so that you could use its mapper support, without DOS2 file system. The unavoidable question: who's gonna do this? 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: MegaRAM
Marco Antonio Simon dal Poz <[EMAIL PROTECTED]> wrote: > > > Is Crazy Train really made by Sony? AFAIK, it's made by Konami. > > > > Doesn't the title screen show the name Sony? We were both right. The title screen shows: "Sony HitBit - Crazytrain - (c) 1983 Konami". So I guess, that's: made by Konami, 'presented' by Sony. Can we rest this silly item now? > > > I didn't know that 41 42 xx xx can't be used for page 0. Can it be used > > > for page 3? > > > > No, "A", "B", xx, xx only works for pages 1 & 2. Ofcourse, there's > > nothing preventing you from putting code or data in a ROM in page 3, > > just a bit difficult to use. > > For page 3 the ID code is 41 42 xx xx or 43 44 xx xx? Alex Wulms explained it quite well: you can put your ROM software in any page(s) you like. The CSxx-signals are not essential, but just for the convenience of the cartridge makers. The BIOS only searches for "AB" in pages 1 and 2. And MSX2 and higher for "CD" in page 0 (subROM). There's no direct relation between each piece of your ROM software, and the need to have "AB" or "CD" in some location. This only needs to be at A place where it is searched, so that your software can start. Examples: most 32K ROMs, and megaROMs have "AB" only in page 1. THAT is found, the init address called, and the code there determines in what slot it is, selects that slot in page 2 as well, and if needed, continues with ROM mapper initialisation. There's no reason either why you couldn't have "AB" codes in pages 0 or 3, either. However the BIOS will only FIND these "AB" codes if they're in pages 1 or 2. So if you want your software to start, you should ALSO have this "AB" and init-address in page 1 OR 2 (or both). If you have "AB" in pages 0 and/or 3 ONLY, and not in pages 1 or 2, then your software won't be found/called. > [...different cartridge versions...] > > Why someone would do it? Is it some kind of unuseful work? But my main > problem was that I couldn't copy River Raid and Beam Rider cartridges. Why? Bugfixes? 'Hooks' for easy development/testing? Who cares? They just are. > > > Yep, I don't know why ROM doesn't search for cartridges in page 0. Perhaps > > > this is due to hardware limitations (pins PAGE1, PAGE2, PAGE12 or > > > something like that). > > > > I don't know either. It's no hardware limitation, though. > > Perhaps it's only an ENASLT limitation. But ENASLT isn't used while > cartridges are being reserched over the slots. AFAIK, the startup routines > use only CALSLT. It's NO hardware limitation. And it's NO limitation of slotswitch routines either. The routines like CALSLT, RDSLT, WRSLT, ENASLT etc. can all work with ALL 4 pages. Only condition is that the stack is not in the same page you are accessing. > > > With a SCC cartridge, you will always find certain blocks > > > in each memory area after reset, otherwise the game might > > > not re-start each time. > > > > You're saying that SCC cartridges have an internal startup > > circuit, aren't you? > > A hardware reset just *resets* these block selections to > pre-defined values, just like it resets the Z80's program > counter to 0. > > This startup circuit puts only the block 0 in area 4000h or put also > blocks 1, 2 and 3 in area 6000h, 8000h and A000h? A hardware reset resets all these 4 memory ranges to blocks 0,1, 2 and 3, simultanious. The same goes for most other Konami megaROMs. How this is for other megaROMs, I don't know. > [...megaRAM initialisation...] > Then your idea is to create a circuit that disables write and disables > block selecting simultaneously, and enables block selection or write after > an access on port 8Eh? That's not compatible with the most part of > Megaroms! The idea is like this: you add another single bit register. This gets cleared or set with a hardware reset. In this hardware reset state, this bit disables both blockswitching and writing to the megaRAM. Any ACCESS to the megaRAM's I/O-port toggles this bit, re-enabling the functions AS THEY ARE FOR THE MEGARAM. So this extra 1-bit register wouldn't get involved in normal megaRAM control, but only toggle between "disable normal megaRAM functions" and "enable normal megaRAM functioning". Ok, it would take some more electronics. That's for the designer to decide: give it more functions, making it more powerfull or versatile. Or keep the hardware as simple as possible, limiting its possibilities. > >
Re: 'advanced' 7 MHz.
Manuel Bilderbeek <[EMAIL PROTECTED]> > > -You have to connected a signal for every single piece of hardware > > that requires 3.58 MHz. access: VDP, MSX Audio, MSX-Music, diskaccess > > (sometimes), Gouda's SCSI interface, etc. etc. etc. > > What??? Does my Gouda SCSI interface need 3.5MHZ??? I thought I could double > it's performance with your MSX Super Turbo to 200kB/s! I don't know how it is on other machines. I just know the Gouda SCSI interface (ROM v1.51) only worked on MY computer with: -turbo switched back for all I/O ports (read: including the I/O ports where the SCSI controller is on), AND -turbo switched back for the cartridgeslot the interface was in This way, it worked up to 8 MHz., on MY system. (but in essence, system running on 3.58 during harddisk transfers). If connected different, it could work, but not reliable. BTW. the manual itself warns that 7 Mhz. doesn't work well with the interface. I still think it's a software issue. > Does your MSX Super Turbo switches back for every I/O access? Same as with 7 MHz. circuits: If the Z80's IORQ signal is connected to one of the inputs: yes If the Z80's IORQ signal is not on one of the inputs: no (IORQ = Z80 pin 20) 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: Discdrive
"Someone" ([EMAIL PROTECTED]) wrote: > I've got a nms8245, but the discdrive doesn't work very well anymore. > (actually it doesn't work at all.:)) > And now i have noticed that all nms8245 drives have the same kind of > problem. > So I'm searching for a new discdrive for my 8245, but I don't want > the standard discdrive for the 8245. The 8245 drive has very often the problem that a rubber band in it starts slipping -> disc doesn't rotate anymore. There seem to be replacements available for this rubber band. Try that first; if that was it, repair is quick, easy & cheap. > Is this possible; > - can you put a normal doublesided drive in a nms8245? You can. > - And where can I get one..?? In any computer or electronics shop. You can use the normal 1.44 HD/DD drives. Only thing you need to change is the connector. I think the required data is in the Ultimate MSX FAQ (www.faq.msxnet.org). 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: Problems when changing stack
Nestor Soriano <[EMAIL PROTECTED]> wrote: > Hi people... problems again... this time, when changing stack. In a new > update of NestorAcentos I'm developing, I put the following piece of code > attached to the timer interrupt hook. The code is placed in a reserved zone > on page 3: > > ld (SAVESP),sp > ld sp,NEWSP+100 > push all > . > . (changes slot and segment on page 2, do stuff and restores old status) > . > pop all > ld sp,(SAVESP) > jp old interrupt hook > > SAVESP: dw 0 > NEWSP: ds 100 > > Well, a program executing such code causes the system to crash when any > other program is executed. Someone knows where is the problem? Advanced interrupt programming ;-)) Isn't it possible, that sometimes a next interrupt occurs, while a previous interrupt routine is still being processed? If that happens everytime, it will crash, but if occasionally, then no problem with proper written interrupt routine. For this to work, the interrupt routine should be re-entrant: allowing to be executed again, even when not finished. Try the above: save (FIXED address), stackpointer ... (interrupted again) ... save (same fixed address), stackpointer for 2nd interrupt restore stack for 2nd interrupt finish 2nd interrupt (=return to previous interrupt handling) restore stack for 1st interrupt, with SP that was overwritten by 2nd interrupt -> SP corrupted -> crash/hang Solution: Disable interrupts (DI), then save SP etc., don't call anything that could re-enable interrupts in between, restore SP, and only AFTER that restore, further interrupts could be allowed. OR: if possible, don't switch stacks at all. Other possibility: 100 bytes stack space reserved? Are you sure that is enough? (try making far bigger, and see if still crashes) 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: mapperports
shevek <[EMAIL PROTECTED]> wrote: > The only thing you need to expect is that writing the data you read from > the mapperport will set it back to the state it was in when you read it. > All other info about the mapper can be obtained by writing to the port and > reading and writing the memory. If the mapperports are write-only (possible), or reading back doesn't work good (possible), reading back will get you "undefined", usually FFh. Writing that to restore, would select always FFh = not the same as previous state. I consider this issue like this: -You ARE allowed to read these ports (why not?). -When you do, there's no telling what you'll get. So you can read these ports, but what you read, should be considered as useless. >> You also have to take care that some people have more then 1 >> mapper (however this is technically not allowed , but who cares) Multiple mappers not allowed? Says who? Says what? Why not? There are some machines that have a hardware-problem with it, but that's more like a mistake in the design of those machines (like the Turbo-R with >512K external mapper). 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: 'advanced' 7 MHz. (was: MegaRAM)
"Laurens Holst" <[EMAIL PROTECTED]> wrote: > >Yes, and why not 7.16MHz MSX1? BTW, how does a 7.16MHz works? I didn't > >change the main clock of my MSX2 because I know that V9938 won't work. > > When accessing the I/O-ports (there's a pin on the Z80 which indicates it) > the board switches the processor back to 3.5 MHz... Later, 'smart' > 7MHz-boards (called Advanced 7MHz) appeared, which only switched back to > 3.5MHz when there was VDP I/O. This way, SCSI, Memory, MoonSound etc. I/O is > all done at maximum speed. > > I'd like to have the last one too (or better: 10MHz!) but I don't know where > to get it... If you have 7 MHz., you have it! There's no different boards or ciruits here (well...mine and 7 MHz. are different!). The turbo circuit (mine OR any 7 MHz.) just runs at high speed, until it is signalled to step back to 3.58 MHz. For this signalling it has a number of inputs, that you can connect to signals, that are activated for parts that can't run on high speed. Usually, there are only 2 connections here: a manual switch, and the Z80's IORQ-signal. That way, it runs on high speed, until (manual switch used) or (access to ANY I/O port). This "smart/advanced" as Laurens calls it, is just other connection: IORQ signal removed, but replaced with VDP's IORD and IOWR signals. That way, instead of for ANY I/O port, it is switched back only for access to VDP ports. You can connect any other signal here: floppycontroller or diskROM chipselect for slowing on diskaccess, some ROM chipselect, if it's a slow ROM not suitable for 7 MHz., chipselect of internal MSX-Music, etc. etc. Using this construction can be faster, but in practice, the difference you notice is small, and many disadvantages: -You have to connected a signal for every single piece of hardware that requires 3.58 MHz. access: VDP, MSX Audio, MSX-Music, diskaccess (sometimes), Gouda's SCSI interface, etc. etc. etc. "Slower" construction is only 1 signal (Z80's IORQ) -Every cartridge you use that doesn't work on turbo, has to feed this switch-back signal back to the computer somehow. For example, if you have MSX-Music cartridge, you would have to switch back for chipselect of MSX-Music IC. But: this is not in the computer, only inside the cartridge! Most practical solution is to put this signal in the cartridge on a reserved cartridge-slot pin, and connect this cartridge-slot pin in the computer with the turbo circuit. That's a big hastle, modifying a bunch of cartridges this way, and: only for use on a particular machine! -Sound cartridges usually still won't sound right on turbo, untill they have their own internal 3.58 MHz. clock added. And you might think all is working, but find out later, that yet another piece of hardware doesn't quite do it on turbo. Or not anymore, if you add another MHz. to the turbo clock speed. Examples: the mouse, HD interfaces, fast diskROMs, etc. etc. Why have this much trouble, for so little gain? 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: MSX2 & memory mappers
"jam" <[EMAIL PROTECTED]> wrote: > You are wrong. Every MSX2 must have Memory Mapper. Even with only 64K > of RAM, it's mapped RAM. Read the MSX2 Technical Handbook (by ASCII) > and check it. Nestor's (Konamiman) online version of the MSX-2 technical handbook clearly reads: minimum, required: 64 K RAM memory mapper: OPTIONAL -> the MSX-2 standard DEFINES memory mappers, but does NOT require 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: BrMSX mapper emulation
Ricardo Bittencourt Vidigal Leitao <[EMAIL PROTECTED]> wrote: > The MegaRAM was not added to BrMSX to improve game play. > Instead, I added it as a development tool. > > I don't know what is your opinion, but I think it's much better to > develop programs in an emulator than in the real machine. I can compile > large files very fast in the PC, using a cross-compiler, and to test it, I > use the BrMSX fudebug (I think it's the best MSX debugger available, > mainly due to the step-by-step tracing and true breakpoints). I prefer emulation as well in many cases, if it's good. I also wrote a BASIC program once, to simulate the dynamic behaviour of a power supply (including the transformer's wire resistance, diode voltage drop, peak currents, voltage difference needed by regulator etc.), to optimise for efficiency and reliability. Adjusting the variables in that is much easier than getting out soldering iron and voltage meter and change a real power supply under construction. > As a matter of fact, both "MUST" and "VIP" were 100% developed in > the PC, I just used the MSX to test the final version. Of course I > couldn't just the BrMSX mapper emulation - I don't have a real memory > mapper at home, and there's no point in developing programs for a system > you don't have. You're writing an MSX emulator, and you don't even HAVE a memory mapper? Go get one! BTW. Adding memory mapper emulation to a MSX-1 emulator should be easy, and really usefull. There's lots of programs that claim to need MSX-2, but can run on MSX-1, if it has a memory mapper. Unusual combination, but works fine! (my R-Type crack runs on that, for example ;-) Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msxMSX 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/)
MSX2 & memory mappers
Hi all, Ooohh, it's really hard to explain those Brazilians all about memory mappers! (don't they have any?). Some facts: An MSX2 doesn't need to have a memory mapper to be a true MSX-2. Example: Sony HB-G900. 64K RAM, no mapper, but true MSX-2, nothing wrong with it. Apparantly there exist Philips MSX-2's without a mapper (not the 8220, which has a mapper), because I made a schematic once for building 128K mapper in those (if all Philips MSX-2's had mappers, I wouldn't have). I suppose the VG 8230 could be such a machine. If you have a VG8230: check it! Does this one have a mapper, or not? Be sure it is a 8230: I've helped build a 8235 into a 8230's casing once... 128K mappers in <>Philips machines: Sony HB-F9P: 128 K, mapper Smaller: Almost every Japanese-built MSX2 or 2+: 64K mapper Philips NMS 8220 has only 64K, but this IS a mapper. Really a 128K mapper with 2nd half empty, so switching blocks, you get: Block 0, 1, 2, 3, "nothing", "nothing", "nothing", "nothing", block 0 again, 1 again, 2 again, 3 again, "nothing", "nothing", "nothing", "nothing", 0 again, 1 again, etc. Not standard? Absolutely standard! Mapper=64K = 4 blocks (0-3), selecting block 0, 1, 2, 3 gets you mapper blocks 0, 1, 2, 3 -> all ok. Reading the mapper ports on this machine would return other values as you might expect, but reading mapper ports SHOULD be considered unreliable, right? Bigger: Turbo-R: 256K (ST) or 512K (GT), mapper Sony HB-G900AP (note the "A" in there!): 512K or 1 MB., mapper 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: MegaRAM
the same that was selected. Then, the RAMdisk-software won't be run. That would be fixed with the above. > > And having the same block selected _all_ the time in some memory > > range, could be a big restriction for that RAMdisk-software. > > Yep, but it's unavoidable, because the RAMdisk-software makes the > management of the Megaram used as a ramdisk, and to do it, it's necessary > that the software be present to the bus, so one memory block will be > fixed. I think that this restriction is much worse with Memory Mapper. Not so! Software inside the megaRAM could copy some of itself into other RAM, and call that copied code. That code could even switch away the megaRAM entirely. Many diskROMs do this kind of thing. > [...mapper detection routine...] "MARUJO" <[EMAIL PROTECTED]> wrote: >> For mapper size detection, I have seen things like: >> OUT (port),xx >> IF IN (port)=yy THEN "big enough" ELSE "not big enough >> mapper" > > Registers aren't user RAM memory. > Registers only controls expanded address bus! (port) = mapper-port (FC-FFh) > I don't believe it. Full detection if 8 cartridges of > different quantities of RAM ? Withouth IN A, (F_h) ope > rations ? Yup, can do that, and no IN,(xx) in it. BTW: MemMan does this too, or should be able to. And MSX-DOS 2 as well... And 2+/Turbo-R on a hardware-reset > [... ramdisk software using Megaram blocks instead of using an EPROM ...] > > > This would require a disk to be specially booted to convert Megaram to > > > Megaram-Disk. But Megaram-Disk is supposed to work like a disk-interface, > > > and like that, it should work fine when it's connected alone, without > > > disk-drives. Then, there's no way to make it without an EPROM. > > > > If you would modify it to have a clearly defined state after reset, > > you could. > > But how could I load the RAMdisk-software? Don't say by tape! Examples: With harddisk-interface & megaRAM connected, install megaRAM software. Reset, and: harddisk + megaRAM-disk available. Install software from floppy. Reset with CTRL: drive A=megaRAM-disk, B=floppy (or the other way round). With battery backup-upped SRAM: install megaRAM-software on any machine with a diskdrive, then use megaRAM-disk on ANY machine (with OR without other drive). Or use Flash EPROM for the megaRAM? Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msxMSX 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: 1.44 MB. disks?
Marco Antonio Simon dal Poz <[EMAIL PROTECTED]> wrote: > > >Do you know a FDC that supports 1.2Mb and 1.44Mb drives and is still being > > >produced, and have good documentation? > > > > Note that 3.5MHz is too slow to allow reading of 1.44MB disks. The "inner > > loop" of the sector read routine is too slow to cope with the data flow. So > > if you want to create 1.44MB drives for MSX, you either have to use 7MHz > > Z80 or use some kind of buffer for reading sectors. > > Are you sure? A 720kb disk works with a FDC that handles 250kbits/s, a > 1440kb disk works with a FDC that handles 500kbits/s. This means that the > main routine should be able to read 12500 bytes per turn. It means that > this routine should run 12500 times in 0.2 seconds. Then, the routine > should spend a maximum of 16 microseconds. In a 3.57561149MHz, this means > 57 clockcicles. > > LD HL,address > LD C,D3h > LOOP: IN A,(D0h) ; 12 clocks > RRCA; 5 clocks > JR NC,LOOP ; 9 or 12 clocks > RRCA; 5 clocks > RET NC ; 9 clocks > INI ; 21 clocks (I guess) > JP LOOP ; 10 clocks > > Total: 71 clockcicles. Conclusion: you're right, it's not possible to use > 1.2Mb or 1.44Mb disks with Z80 at 3.57MHz. It's BAD! In principle this could work! The 2793 floppycontroller HAS the capacity to handle 500 Kbit/s (apparantly, this was used for larger 8 inch disks -a lnnngg, lnnngg, time ago). Can the Z80 handle that? 500 Kbit/s = 62.5 Kbyte/sec. 3.58 MHz / 62500 = 57 clockticks per byte. A bit tight, but possible! Take the above loop: LOOP: IN A,(D0h) 12 ticks RRCA 5 ticks JR NC,LOOP 8 ticks if skipped, 13 if jumping RRCA 5 ticks RET NC6 ticks if skipped, 12 ticks if returning INI 17 ticks JP LOOP 11 ticks If the 1st JR is done: 12+5+13=30 ticks, far less than 57. Otherwise 12+5+8+5+6+17+11=64 ticks, a tiny bit too many But speed-up's are still possible here: -Drop the JP at the end, and put what's before it xx times after each other. Doesn't look nice as source code, but works. You could also copy this piece of code xxx times to RAM and execute that -put address of (LOOP) in IX or IY, and replace JP LOOP with JP (IX) or JP (IY): takes 9 instead of 11 ticks. Or even use JP (HL): uses only 5 (!) ticks -INI and instructions working with pointers use 16-bit counters. Could be replaced with sequences like INC HL: DJNZ LOOP. If you take a fixed transfer address (sector buffer!) with start address xx00h, you can replace that INC HL with INC L. -The memory mapped I/O construction used by the floppycontroller in European MSX's gives more instructions that you could use (more Z80 instructions dealing with memory than with I/O) -Do the INI in the above loop for starters (!): increases pointers, AND sets flags! -> Allows to test those flags immediately (=drop another 5-tick instruction). If a byte did come in, you're done, if not, simply decrease pointers again Combining the above: not easy, but it COULD be done ! 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: Round 16... FAT! (help wanted!!)
Nestor Soriano <[EMAIL PROTECTED]> wrote: >> SET the disk change flag? Why do you need to do that? > > The behavior of my driver when a function call is made is the > following: > > - Check if the disk has been changed via CALL #4013. > - If not, read an internal table which contains the type of the > drive. If FAT16, process function call. Else (FAT12) do not > process and let DOS to do it. - If yes, read boot sector in > order to determine the type of drive. If FAT16, build new DPB > and process function call. Else, let DOS to do it. Update the > drive type table in both cases. > > Well, suppose that disk was changed and it is FAT12 type. My > driver must do nothing and let DOS to execute funtion call. But > what will do DOS at first? To check if the disk was changed. But > my driver did it already!! So DOS will obtain a "disk not > changed" status, even if the disk was changed, and will not > update the drive's work area. This is very dangerous... > > How to solve it: if the disk was changed and it is FAT12, set > again the disk change flag, so next call to #4013 (check disk > change), performed by DOS, will return "disk was changed" > status. I know how to do it but only on MegaSCSI. You could figure out how to set this disk change flag for other interfaces, but it's disk hardware-specific, so better leave it alone... Possible solutions for the above: -Avoid making a "disk changed?" call. If you do need it: maybe you can use the result of a "disk changed?" call made by DOS earlier? -Maybe you can use another interception point for your routine, at a point where DOS already determined this disk change status? -DOS does this call again, after your code? Maybe you can use a different exit point from your code, skipping this next DOS call, and pass on the result of the "disk changed?" call you made? -Or: intercept somehow this next "disk changed?" call made by DOS (difficult, tricky) > >If it only works with MegaSCSI, then it's really a MegaSCSI > >modification, not some kind of 'driver'. If so, I think you'd better > >re-do it. > > No. It is NOT a MegaSCSI modification, because I don't change anything of > MegaSCSI SRAM. My driver resides in a RAM segment. Besides when a FAT12 > drive is accessed, my driver does nothing, and normal DOS code is executed: > no modification at all then. MegaSCSI modification = adding something, that only works with megaSCSI, not other interfaces. What it does with the megaSCSI itself, or where that added code stays: I don't care! > >b) If possible, simply return/jump back to the original end of a > >routine? > > What? Sorry I don't understand what you mean. Anyway I think you are maybe > speaking about "ignore" option, not "abort"... Dos HAS code for handling "Abort", right? You can do the same, but instead, you could also jump back to that DOS code handling "abort" (and don't care what happens from there). That was the idea. > I also don't know how sector buffers works, as well as "fork a child process" > (what the hell is this???) X-) See MSX-DOS 2 function call documentation, functions 60 & 61h. 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: MegaRAM
state "undefined".
Why is this important?
-
Suppose you want to make a RAMdisk-software using the megaRAM, that
you want to be reset-proof.
*If* a reset would force the megaRAM in block-select (read-only)
mode, and select say, block 0, for some/each memory range, then a
reset would make that RAMdisk write-protected at once, and you could
just put initialising code in that block 0.
But if you don't have that reset-effect, the only way to have that
initialising code start on every reset, would be to keep -some- block
ALWAYS selected in for instance 4000-5FFFh range, so that it will
always be there, no matter when the thing is reset.
And having the same block selected _all_ the time in some memory
range, could be a big restriction for that RAMdisk-software.
> > Simple and good method: select (in descending order) each possible
> > block, write its number in it in at some test address, and then
> > (starting with block 0) check up until which block the block number
> > matches what you find at the test address when selecting each block.
> > In pseudo-code:
> >
> > FOR n=255 TO 0 (decending order!)
> > Select block
> > Write to test-address
> > NEXT n
> > FOR n=0 TO 255
> > Select block
> > IF (testadress)= THEN NEXT n ELSE highest block found (=n-1)
>
> I think that this method has a fault: if a 256kb Mapper has 8-bit
> registers and the blocks from 16 to 255 points to null memory, this
> technique can detect 17 blocks insted 16, because when you read the block
> number 16 you get junk, and this junk can be 16 (the probability is
> 0.390625% but it's not 0%).
Okay, test each block to be RAM first ("junk" won't pass then).
Anyway, chances of reading any "null" value other than FFh is small,
and reading a value of 16 (0001 binairy) is more like 0.001%
> > I wrote a superbly constructed memory mapper detection routine once.
> > Detects ALL (including full 4096, those stupid 192, 384K etc., or no
> > mapper at all) sizes correctly, doesn't change the contents of the
> > mapper, AND does it without using any buffer memory.
> > (mapper size detection built in DOS2 cartridge uses 256 byte buffer
> > memory for that, my routine does without).
>
> That's very good! Can this routine detect multiple mappers installed in a
> MSX?
What's so difficult about that?
Select 1st slot - test mapper size
Select next slot - test mapper size
Select next slot - test mapper size
etc.
Add total sizes, put it in a table if you like - what's the big thing
here?
> I am thinking in redesign my routine for Megaram size detection, allowing
> non-standard sizes to be detected. And I would like do detect multiple
> Megarams, what I have never made. I think that it would be very good if
> the Mapper-detection and Megaram-detection routines were the same (unique
> routine for all kinds of memories!)
Shall I do that? I'm good at this kind of thing;-))
> > BTW: Instead of adding the extra EPROM to create a MegaRAM-disk,
> > wouldn't it be easier to put this disk-driver software in the MegaRAM
> > itself, together with the contents of the RAM-disk?
> > (maybe with some extra reset circuitry, or SRAM battery backup).
> > This would also allow really easy update of such disk-driver
> > software.
>
> This would require a disk to be specially booted to convert Megaram to
> Megaram-Disk. But Megaram-Disk is supposed to work like a disk-interface,
> and like that, it should work fine when it's connected alone, without
> disk-drives. Then, there's no way to make it without an EPROM.
If you would modify it to have a clearly defined state after reset,
you could.
This need not interfere with other MegaRAM use. And if you want to
reset the machine with the megaRAM in some other state, simply set
that state, and do a software-reset.
>> (Brazilian vs. European floppy-controllers)
>
> So do I. Recently, Alex Wulms explained to me how these FDCs work, and
> they work like the port based FDC. The main difference is that addresses
> 7FF8h-7FFBh is mapped to ports D0h-D4h. There are other minor differences,
> but they are not important.
You mean the same FDC (2793) is used, just put on I/O ports instead
of memory-mapped? Could you check that, if it's the same IC type?
BTW: I hope you read "these FDCs" above as "these 2793's", because
the 2793 and other FDC's like TC8566 are *really* different.
Differences between the 1793 and 2793 are probably not that big, but
I wouldn't swap diskROMs between these.
> And do you know what's the differences between WD1772 and WD1793?
Forget it..!!
TMS 2793 = "obso
Re: MegaRAM (was: cracked 24k ROMs)
Marco Antonio Simon dal Poz <[EMAIL PROTECTED]> wrote: > > >But Hinotori is a 128kb game. So, why do you need VRAM? > > > > The ROM is 128K and it also needs some RAM (probably 16K) to run. > > And ROM pages are 8K in size, mapper pages 16K. This means that sometimes > > you need to duplicate ROM pages in the mapper to allow all combinations > > used by the game. Example: ROM page 0 and 4 are used together, just as ROM > > page 0 and 13. In the mapper you'll need 2 pages (32K) for those three 8K > > pages (24K). > > If you have 256kb of RAM, there's enough space to do all the necessary > combinations. Or am I wrong? Suppose you have 128KB (1 Mbit) ROM = 16 blocks (0-15) of 8 KB. If you want to have all combinations with block #13 in the lower half of a 16K page, than you need to store combinations 13+0, 13+1, 13+2,,13+15 = 16 mapperblocks needed for instant retrieval. The same for block 0, 1, 2, etc., and combination of blocks 13+2 needs its own mapper block next to combination 2+13. So you would need 16 x 16 = 256 mapper blocks = 4 MByte mapper for this. (damn, this could work! does anyone feel like writing a loader for this, so that you could run most or all 1 MBit Konami's just like that, if you happen to have a 4 Meg mapper?) 2 MBit ROMs = 32 blocks -> 32 x 32 mapper blocks = .... (slotexpander filled with 4 mappers of 4 Meg each) 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: 64K VRAM?
Coen van der Geest <[EMAIL PROTECTED]> wrote: > > MH> It is possible to make an MSX2 with only 64K VRAM. Such a machine > > MH> would not have SCREEN 7 and SCREEN 8, not even a single page, because > > MH> VRAM timing requires two RAM ICs connected. Does anyone know if > > MH> machines with 64K VRAM were ever actually made? > > > >Mitsubish ML-G1 had 64K VRAM, I think. > > Philips has one also, I don't exactly know which type it was, but they > did have one. And it was not the 8280 :-) (nor was it the 8235, because > I had that one, nor the 8245 and 50, so it must have been one of the > others). And I actually knew someone with such an MSX (grin :-) ) Maybe you mean the NMS 8220? That machine had only 64K RAM (normal memory mapper), but did still have 128K VRAM, like every MSX2 I've ever seen... Looks on the outside like a 8020 MSX-1 (with darker case), but with MSX-2 inside (no diskdrive built-in, but some Designer-plus like program in ROM as an extra). A bit like a NMS 8245 with the disk-electronics stripped from it. Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msxMSX 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: Round 16... FAT! (help wanted!!)
Nestor Soriano <[EMAIL PROTECTED]> wrote: > Yep, tired of searching technical info, and since nobody does anything (eh > Pazos! Esto no va por ti; yo ya me entiendo) I started my FAT16 driver. > Unlike Pazos&Okei one, it is not a patch for diskROM, but a completely > self-made driver which will be placed into a RAM segment. > > I'm making it for MegaSCSI, but the controller dependant routines (just > three routines) are clearly separated from the rest of the code, so anybody > can modify it for any other controller. I am really sorry to have to write this, but: Doesn't a FAT16 driver modify the disk system, and not the disk-I/O itself? For clarity: with 'disk system' I mean here: the non-hardware dependant software, that for instance resides in an ordinary DOS2-cartridge. With 'disk-I/O' I mean: the low-level, hardware-dependant part of diskROMs. If so, a FAT16 driver should not in any way depend on a certain type of hardware/ROM, only change things that are the same with any disk interface. Or any DOS2-using interface, if you like. A FAT16 driver changes the FILE system, and thus should work with any type of disk that supports that file system, in this case: any disk hardware that could support FAT16 formatted disks, not just MegaSCSI. If it only works with MegaSCSI, then it's really a MegaSCSI modification, not some kind of 'driver'. If so, I think you'd better re-do it. > I almost finished the "basic engine" but I have problems with the error > handling part, so I ask for help. Here is the problem: > > [HI-TECH MODE ON] X-) > > Imagine that a function call is being executed. Page 2 contins the DOS data > segment. Page 0 should contain the DOS code segment... ... (...more tech speak...) ... > - Restore TPA segments in pages 1 and 2 > - Load C=#62 (program terminate) and B=Error code > - Jump to #0005 in TPA segment of page 3, via inter-segment call > > It works and COMMAND.COM takes control, but next execution of a program > causes the computer to hang. > > [HI-TECH MODE OFF] > > SOS... help... maidai... dios mio, esto es un infierno... X-) I just need > to solve this problem for having a "releasable" version of the driver (I > hope!!). Also, any suggestion & beta-testing offers will be welcome of course! On error handling: Why not - a) Start & end your routines as much as possible the same way as is done in the original routines (do some disassembling & code copying, only squeezing your own version of the interesting parts in between), or b) If possible, simply return/jump back to the original end of a routine? 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: YES! Harddisk is working! But...
a ROM, or would additional circuitry be needed? Does anyone have some datasheets of this controller (AMD or WD 33C93)? > 11 - Are the speeds I got with HDSPEED reasonable? What is the speed > with a new Novaxis ROM? And what on 7MHz? (Twice as big?) And with both > 7MHz and new ROM? If floppydrives get to 12-15 KB's/second, who cares whether your HD works 8 times, or 15 times faster than that? Anyway: 7 MHz. and the Gouda (Novaxis) SCSI interface just don't go well together. Frankly I wouldn't know why not, such controllers & HD's are made for far higher data rates, so I suppose it's a pure software-problem. The software is THE problem with the Novaxis SCSI interface. For instance: If you only have one HD connected, with a SCSI-ID that is SOMETHING else than the interface, the intelligent way would be to scan all ID's on the SCSI bus at boot time, and make a drive-letter for every useable partition you find. Not so with the Novaxis interface: you have to set a 'target-ID' for the HD, set a 'host-ID' for the interface, and if the target-ID isn't right, the interface will make you wait lnnngg after every reset, and doesn't initialise any drives. There is LOTS of such shortcomings like this. When all is okay, it works okay, and fairly fast, but if things aren't entirely right, it works SHIT. Apparantly the Bert and Mega-SCSI do better in this respect. Partition table formats are quite standard for PC's, and if you use a same format, you can exchange files easily with other HD users. But even though it doesn't offer ANY obvious advantage, a lot of MSX HD interfaces (and versions) use different partition tables, incompatible with one another. There is one REALLY simple solution for this: 'standard' partition formats are known, for every incompatible type it would be enough to: -Write a bare-bones utility to convert existing partitons, or create new ones to the standard format. -If neccesary, update the interface software to work with this standard partition format. 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: MegaRAM (was: cracked 24k ROMs)
Marco Antonio Simon dal Poz <[EMAIL PROTECTED]> wrote: > > Is it possible to make the MegaRAM yourself using all new parts? > > Or do you need old cartridges? > > Anybody has any schematics? > > It's perfectly possible. You can use the same memory IC's used in Memory > Mapper. The difference is only the block switching circuit. > > I don't know anybody who has the schematics, but it's not very difficult > to create one. The special feature is the port 8Eh, that selects between > BLOCK SELECT mode and WRITE ENABLE mode. > > In a Megaram, when you execute a "IN A,(8Eh)", you put Megaram in WRITE > ENABLE MODE. The accumulator receives garbage. When you execute a > "OUT (8Eh),A", you put Megaram in BLOCK SELECT MODE (exactly as a Megarom > cartridge), whatever the contents in the accumulator. > > In Brazil, we have Megaram models of 256kb, 512kb and 768kb. Okay, just so that anyone can build this, or emulate it (oops...), can you please fill in the details? -IN xx,(8Eh) sets "write enable mode" -OUT (8Eh),xx sets "block switch mode" I suppose this can be made using a single 1-bit register, that responds to access of I/O port 8Eh, and taking either read- or write-signal as data input. D0-D7 lines are don't cares when accessing this I/O port. -Is this a single I/O port (8Eh), or mirrored on other I/O-addresses? 2? 4? 8 I/O ports? -If in "write enable mode", I suspect you can write to the current selected blocks in certain memory ranges. Is this correct? Or just one special block or so? -What size blocks are switched? 8 KB? 16 KB? Smaller? Bigger? -EXACTLY what memory ranges do these blocks occupy? -EXACTLY what memory ranges can be used to switch the blocks (if in "block switch mode")? (tells the hardware designer which address-bits are don't cares) -What block numbers are allowed (# of bits)? -How are unused bits in block numbers handled? Suppose you have 32 blocks (5 bit block numbers). What happens when you try to access block numbers of 32 and above? Are higher blocks 'empty'? Are unused bits in block numbers treated as don't cares? -Can you read the selected block numbers back, or are these write-only? (for instance: most ROM mappers: write only (mapper registers, that is, not the ROM data ofcourse), normal memory mapper: read & write block numbers) -What's the power-on / reset state? Everything "don't know"? Or blockswitch-mode, but currently selected blocks undefined? Or: block xx in memory range yyy-, block ... in memory range etc.? Finally this: what software exists, that actually USES this MegaRAM? Greets, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msxMSX 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: Cracked ROM in 24k portions
Manuel Bilderbeek <[EMAIL PROTECTED]> wrote: > I have some cracked ROMs with 24kb blocks. Very quick to load, but the > disadvantage: it's from &H8000-&HE000 (or somewhat higher for the code > that has to LDIR the block in the right mapperpage) in memory, and the > basic loader has to fit in too: result: CTRL needs to be pressed. > > I was wondering, can't someone make a nice ML-loader that stores the > blocks in the lower 32k of RAM? (Using the same blocks, but, instead of > a BASIC loader a ML loader, the RET of the block-LDIR-code will return > to this ML loader then (or something)). > > Can anyone help me with this? > (Cas? Maarten? Jerome?) > -- > Grtjs, Manuel, who doesn't like pressing CTRL before loading something Neither do I... What you might need is what I call a cartridge-loader: Just rip the ROM data out of the files using a debugger or disk editor, put it in one file, and use that cartrige-loader to run it. I wrote a good cartridge-loader once, that will even allow you to exit without having to reset the machine! (works perfect for 95+ percent of ROM files). Available for download on my pages. If you have some nice programs to convert that way (that I don't have yet), feel free to send some to me, for me to do the ripping & glue-ing of the contents. P.S. Preferably packed somehow (for safe transport), and no more than a couple of hundred KB's at once, please? Greets, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msxMSX 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: MSX hardware page...
Hi, Patrick Kramer <[EMAIL PROTECTED]> asked: > Does anyone have a schematic of a memory mapper that can use 1 MB > SIMMs ? Drawing up such a schematic is easy...making print layout & building it, that's the real work. > 2nd question: where do I get 50 pin header connectors or > experimental MSX slot PCB's ? Your local electronics shop should have those connectors. To get such an experimental board: There exist sheets with PCB layout symbols, for creating layouts used as 'masks' for UV photo-sensitive board. You can also apply these symbols directly to blank copper board, and use that for the etching process. There are connector symbols, which have the exact same spacing as the MSX cartridge connector (standard 0.1 inch / 2.54 mm). > 3rd question: anybody happens to have the schematics of a Canon V20 > MSX1 ? Is this an interesting machine on the inside?=;-} > 4th question: does anyone know of a MSX-site that has anything related > to MSX-hardware (schematics etc.) Laurens Holst <[EMAIL PROTECTED]> wrote diz: > I think it might be a good idea if someone started some kind of > schematics-page where you an find all different kinds of schematics > varying ffrom 7MHz-print to SIMM-memory-prints... > > It would be very useful to have these all at one place > (and translated into english!) At least something like it exists !! Current contents of my MSX Tech Doc page: -MSX Super Turbo circuit -256K sampleRAM for MSX-Audio -pointers to datasheets of various MSX parts -links to several other hardware-related sites (not per se MSX-only) The time I spend on adding own data to my site is very limited, but I wouldn't mind if my pages become a nr.1 spot for circuit diagrams and alike. So if you have hardware schematics, datasheets of MSX parts etc. (in electronic form !!), I'll be happy to put those on my pages. BTW. many of such projects have already been published or released earlier (7 MHz, MK megamapper, slotexpander, 2+ expansion etc.) Greetings, Alwin Henseler ([EMAIL PROTECTED]) maintainer of the MSX Tech Doc page http://huizen.dds.nl/~alwinh/msx 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/)
MSKISS 0.2 archive damaged
Hi you all ! I read on this list of a new version of the MSKISS emulator (0.2). Downloaded it to check it out, and the file produced a CRC error, so a damaged archive. Repeating this gave the same result, and a copy on the MSX Emulator Page (M.E.P.) was the exact same thing. I notified the maker, and the guys at the M.E.P., in the meanwhile you'd better wait for a new archive to get uploaded, before you go out and get it. Just thought you might want to know... =:-] 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: disk image formats
Hi...! Maarten ter Huurne <[EMAIL PROTECTED]> wrote: > >Such stupid name hides a useful program: it enables you to create empty disk > >image files of ANY lenght, from 10K to 32500K, as well as standard 1DD and > >2DD disk image files. Of course with valid initialized boot sector & FAT. > > I made something like that as well. My program creates disk images from a > list of files, which are placed in the disk image. > But I have a problem: the DiskROM expects the directory to be located in > sector 7. If you make a really big disk, the FAT becomes larger and sector > 7 will be part of the FAT. Although it is possible to set the starting > sector of the directory in the boot sector, the DiskROM ignores this > information. > If you know of a way to fix this, I will be very grateful. Nestor (Konamiman) suggested to use more sectors per cluster. This won't work! You can have valid disks/disk images, but DOS1 does all format determination simply by checking the 1st byte (the so-called media descriptor) of the 1st FAT; this is hard-coded as sector 1. This works; every disk format that I know that's used on MSX has the 1st FAT starting at sector 1. All other format parameters are set based upon that single media descriptor byte. So if you change the bootsector parameters & disk format, it won't help because DOS1 doesn't use these to determine the disk format. Conclusion: -If you want to use DOS1, use one of the standard MSX disk formats (360/720 K) -If you want to use other disk formats, use DOS2 for accessing these Greetings, Alwin Henseler http://huizen.dds.nl/~alwinh/msx MSX Tech Doc page e-mail: [EMAIL PROTECTED] Please standby... Setup is copying files to prepare the wizard, which will guide you through the process of shutting down your computer. 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
ent diskROMs), which makes figuring out the use of many of those undocumented memory locations and variables a LOT easier. -And I have an essentially complete disassembly of a DOS1 disk 'driver' (originally taken from a Philips NMS 8245 MSX-2), which can be used to modify such a driver on a source code level, and is easily made into a complete diskROM after that. For instance, I used this once as follows: I had a Korean-built MSX-2 at my place for a while, which used a diskROM that I recognised as an older type 'system part' (more bytes free in BASIC, but less performance-optimised). This also used a disk controller I had never seen in an MSX-2 before that: the Western Digital 1772 (even older type than 1793 or 2793, worked perfectly though). For me, with all this, just a couple of days were enough to produce a new diskROM for this machine, using the same driver code, but with an optimised system part (the same as those used in most MSX diskROMs), which made normal disk operation a LOT faster. With the knowledge I had here, the diskROM produced here worked 100% solid right away, like any other separate or built-in disk-interface (I didn't hear any complaints later on either). Just a matter of having the right materials to produce it. 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/)
More and/or bigger drives on MSX
existing programs? If you would support for instance 32-bit sector
numbers here, how to handle programs that don't support it? If you
would define a 'new' function call for this, what would the practical
use of this be?
When you take file operations: if I'm not mistaken, file offsets are
defined as a 32-bit value in existing DOS function calls. I'd say,
supporting access to normal files, but up to a 4 GB filesize (2^32)
would be a great step forward. If you would implement a 'file
operating system' that will fully support such files sizes using
existing function calls, how will this affect existing programs?
Would this work okay, or would there be all sorts of problems,
created for instance by programs using mixed sector-I/O and file-I/O?
Instead of looking for solutions for some of these details, why not
do some proper research on the general issues here?
What might be REALLY usefull here is this: an overview of the exact
use that several popular or 'essential' EXISTING software makes of
the existing DOS functions. If you know that a particular SET of
programs only uses a particular set of DOS functions (like memory
locations xxx, and function calls yyy/zz), then you also know that
you can continue to use these programs with 'DOS3', if it would
SOMEHOW implement THAT set of function calls & memory locations.
Instead of wasting time to figure out HOW you could do that, you
could first figure out, WHAT would be needed to implement a 'DOS3'.
What functions would HAVE to be implemented, with what things should
it remain compatible, in order to make it any use?
So, on the other hand, support/implementation of what things could be
dropped, without having every existing program stop to operate?
Why this whole story? Well, simple: why bother making a disassembly
of a DOS2 kernel? You know what happens, when you delete a file on
harddisk, don't you? Some special marker is put into the directory
entry that goes with it, that says: 'deleted file', and the FAT
entries (clusters) that were occupied by that file, are converted
from pointing to next parts of that file, back to 'free'.
You know how a FAT12 disk is organised, you know how to read/write
those sectors using low/level I/O routines. So why bother to figure
out, how exactly this is done by DOS2?
All you REALLY need to know, is how to put such a new DOS together in
such a way, that many existing programs can use it. What memory
locations are 'fixed', and which are free to shift to other places,
or not to use at all in this new disk operating system. So all you
REALLY need to know, is how existing programs use the current
systems. How do they determine what's present (DOS1/DOS2)? What
function calls are used? What memory locations are used? What
assumptions are made?
Instead of debugging your entire software collection, I suggest that
all of you, who would like to participate, find out for THEIR OWN
PRODUCTS, or maybe for one or two of their favourite programs, HOW
these things use the disk system: what system locations are used,
what calls are made, what assumptions were made? Check out some
source codes of some of your own stuff, and make a quick list of ANY
system locations used in relation to disk/file-I/O, and ANYthing that
would have to be in such a new disk system, to make your product
work. If you lost the source, get out your debugger! You still know
roughly how your program works, others don't!
Then, drop your results on this mailing-list, or some volunteer that
collects these results, and after a while, you would get a database,
showing how different programs use the disk system. With that, you
could see in one quick look, what the effect would be, when a certain
modification to the disk system would be made. If you would implement
some higher drive numbers somewhere, with this database you could see
in one look, what programs would support those extra drives, and what
programs wouldn't.
And THEN, it would be far easier, to work on any extensions or
modifications of a disk system. You would know up front, what would
be necessary to make programs xxx (choose any set of favourites)
work, and what would be free to change in a new system.
To conclude: my suggestion here, is to focus any efforts here on the
INTERFACE between existing software, and existing disk system
software. What are the essientials here?
Let's forget about the rest of how these programs work, and let's
forget about how all the details are implemented by disk systems (I
mean, those details that are 'internal'). In other words, let's
figure out, how this INTERFACE works, what is 'external'
('fixed'/'standard') and what is 'internal' (free to change as you
wish) ?
Can we do this?
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: Bigger sector numbers
such a way, that one or more of these
indicate 'new', using some values that will/were never used in the
old system.
Let's see: sector number 0-h: all possible
media descriptor: I've never seen anything below F0h, but I'm not SO
sure about this.
Number of sectors: 0-FFh: could be used, but might give problems if
values bigger than ... are passed to older drivers.
My idea: why not indicate a big sector number with the highest bit of
the drive number (passed with A register)?
If passed to an older driver/part of the system, this would be read
as drive number beyond 127 ('ridiculous'), and any action will surely
be refused in this case, with an error code to go with it.
It would only limit the maximum drive number to be passed this way to
0-127 (who cares), and:
-It's 100% compatible, no h sector number exception
-The 16 bits used previously for the sector number, can be used as
normal, to pass the lower 16 bits of the sector number, instead of
wasting this with a dummy h value
-You can use some special values (FFh, FEh, FDh etc.) for the drive
number to indicate sub-functions, and use this for instance to
'inquire' about supported features, locations of extra info etc. (you
might use this through other entries rather than DISKIO).
What do you think?
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: MSX game: an idea
icated instead, to prevent being erased, or actively hunt down/erase others. An idea I had myself once, was to run a simulation of an ant heap (or several), in a simulated environment. Scientists have always wondered, how it is possible that such simple creatures like ants, or bees, can produce such complex societies, when put together in large numbers. I think the common idea these days is, that for every single ant, or bee or such, the behaviour is controlled by a very limited number of simple 'rules' (some estimated something like 250 very basic rules, together fully describing the behaviour of an ant), and that the resulting complexity simply comes from numbers, and a long evolution of the physical properties, and sets of rules, making up each ant. My idea was, to make a simulation of this by running one or several heaps of simulated ants, were each ant would be similar to the creatures wandering around in computer games: described by a simple set of rules and variables, and simply processed in a row, with discrete steps in time to control their movements. You might take a couple of hundred (thousands?) of ants, put 'food' in random places, place obstacles in the way, or introduce hazards like 'no-go areas', unrelated types of enemies, natural disasters, competing, but differently working ant species, or make different types of ants (workers, fighters) etc. etc. etc., and just watch what happens. Would make a great screensaver, I think! P.S. Does anyone know of such simulations written for MSX machines, and similar 'recipes' for simulations? I gave the above ideas, and I know of implementations of Conway's Live game for MSX (one called 'bosbrand', by the MCCM, and another one written by myself once). But are there more versions of this Live simulation, or other simulations like it, written for MSX? 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: Philips MSX-2 memory layout
Hi again! "See Loy Lin" <[EMAIL PROTECTED]> wrote: > > > > Yeah, I got this problem once. In a MSX2. But DD2 runs fine in my > > > > MSX1, my MSX2 and my TR-GT. Even in BrMSX, VMSX and CJS MSX2 Emulator > > > > (not in fMSX). > > > On my Philips VG8235 and NMS 8245 (both MSX2) exactly the same > > > happened, but now I have a Philips NMS 8255 (MSX2 and with 512 Kb > > > RAM) and the game works perfectly with it! > > > > Can you, please, tell me the memory map (RAM slot/subslot) and VDP > > ports of your VG8235/NMS8245 and NMS8255? I'm curious about this crash of > > DD2... > > I'm afraid I don't know much about the memory structure of my MSX... > However, I will try to look at home for documentation, but has > anyone more knowledge about this subject??? These MSX-2 models from Philips (and the 8280 also) basically share the same memory layout: BIOS/BASIC ROM in slot 0, slot 1 & 2 are the same numbered cartridge-slots, and slot 3 is internally expanded (giving 3-0, 3-1, 3-2 and 3-3), with: 128 KB. memory mapper (8 blocks of 16 KB. each) in slot 3-2, MSX2 subROM in slot 3-0 (address -3FFFh), and diskROM in slot 3-3 (address 4000-7FFFh) You can discover such features easily using some debugging utility, or run MCCM's MSXMEM (it's pre-historic, but still good for this). > > > happened, but now I have a Philips NMS 8255 (MSX2 and with 512 > > > Kb RAM) and the game works perfectly with it! Ehhh, this memory mapper SIZE is not what does it, is it? The VDP ports are 'ofcourse' the same as in any other MSX: 98h: read/write VRAM 99h: read: VDP status, write: VDP commands/register changing These can also be found in BIOS-addresses 0006/0007, as any MSX programmer should know (stupid...you can find this anywhere) 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/)
follow-up: MSX-Audio 256K sampleRAM
Hi you all, In response to a request earlier (from some Brazilian or so), I have uploaded a description of how to connect 32 or 256 KB. sampleRAM to a MSX-Audio chip (Y8950), to my MSX Tech Doc page. See below for the address. Click on the hardware icon to get there. If you want to build it: go ahead, I checked things properly. I only did this once or twice myself, but as described, it works. If you are someone who also did this once, or know how to do this: please check my description, to see if anything needs correction, or maybe it can be done even simpler than I did. I used two 256K x 4 bit DRAM's (44256) for 256 KB. Someone said earlier that that's all that is needed. That is not quite true: a simple inverter is also used. But: in the most likely 'victim' for this upgrade, the Philips Music Module (NMS 1205), you can use an unused inverter, that's already in there. So in this case, only those 2 DRAM's are enough. I included the connections for 32 KB., for those MSX-Audio's that don't have any, and for easy reference. I'd say other sampleRAM sizes are really not of any interest, so you figure that out yourself, if you'd want to. One more thing: does anyone know what software actually uses this extra sampleRAM, that you might use to test it? 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/)
uploaded UNPMA v1.0
Hi all, I have (finally) taken some time to update my MSX-webpages again, and uploaded an unpacker for PMA-files I wrote once. It's called UNPMA (how original), version 1.0 (no newer version needed so far). It was meant as a replacement for PMext. It does not support the many archive formats or options that PMext does, but: -it unpacks PMA files on average 2 to 3 times faster than PMext does -under DOS 2, you can make full use of directory names it works just as well under both DOS 1 and DOS 2 Full source code and documentation is included. You can get it at: http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page) Just click on the software icon. Please read the included doc's first, before firing any questions about it at me. If you still have questions then, and the answer might interest this audience, you MAY also ask me via this mailing-list. Happy unpacking! Alwin Henseler e-mail: [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: Check out!
Laurens Holst <[EMAIL PROTECTED]> wrote: > Take a look at my homepage, I have put up a new section, called: > "The MSX image source"... Here you can find photos of different kinds of > MSX-stuff (I have). Maybe a product of yours is also there!!! Great, so let's visit: http:// ???? 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: Backups...
Hi, "Klaas" (de Wind?) <[EMAIL PROTECTED]> wrote: > > Thay call that making a backup of your harddisk once in a > > while... > > Yep, I know. But when the backup is on a zipdisk, and that zipdisk has a > read-error... A backup that you can't read = no backup Alwin ([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: JoyNet serial transfer routines
I wrote earlier:
> >It's about the exact time(s) of sampling the bit values of the main
> >(RxD/TxD) signal. In asynchronous communications, this is based upon
> >a fixed time for a single bit, determined by the baudrate.
Maarten ter Huurne <[EMAIL PROTECTED]> replied:
> That's synchronous communication. In asynchronous communication,
> there is no baudrate.
[EMAIL PROTECTED]replied:
Van: [EMAIL PROTECTED]
Ehrm... I don't wanna spoil the fun, but for JoyNet, we're talking
about asynchronous communication. What you describe here ("...based
upon a fixed time...baudrate") is synchronous comm.
[Which trashes the whole supersampling idea]
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.
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).
Note that for both ways of communicating there IS a baudrate, only
for asynchronous it is determined externally (and needs to be the
same for transmitter and receiver to have it working), for
synchronous this is determined by these 'extra' signals (call it
'bit-clock' or such). Bit-rate and baud-rate are not the same thing
technically, I wouldn't know the exact difference between these
though.
I do not know exactly what method is used with JoyNet, if it uses a
fixed bit-timing, that would make it asynchronous. If it uses an
extra signal, besides the data-carrying signal, that would make it a
synchronous communication (you figure that out).
Besides: if JoyNet only standardises the cable, than that leaves the
programmer free to choose for a synchronous or an asynchronous
communication method. 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.
Anyway, my suggestions were just that. Whether you think it's needed
to implement these in your applications, is up to you. Generally, I
think:
-For networkgames, SPEED is crucial, and error-checking not that
important, or not at all
-For data-transfer, speed is not THAT important, and error-checking
might greatly improve reliability. If not needed (with good, short
cables, and/or low speeds) it won't matter, IF needed (under worse
conditions), a proper error-detection mechanism can well be the
difference between something working lousy, and something working
normal, but just a bit (!) slower. That's all. And you should know
that less-than-optimum conditions are more common than optimimum
conditions.
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: A question...
Hi again! Laurens Holst <[EMAIL PROTECTED]> wrote: > As far as I know there still isn't a program for the MSX with which > you can (like RAR or ARJ) devide large files into smaller pieces (to > reassemble later) which can, for instance, fit on a disk. > Compression is not even nessacary, just the deviding... Eehhhthat's what I would call a file-splitter... Like the one I just uploaded (Split v1.1) a couple of days ago. So: there is! Alwin([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: POKE -54,35: strange errors!
Can we finally finish this poking stuff? > Manuel Bilderbeek schreef: > > (stuff deleted) > > Erik de Boer <[EMAIL PROTECTED]> wrote: > > this poke let some software belive that there is an expanded bios on boardit just > fills in a hook. > for some software this is enough to let them belive that a msx audio bios is > peresent. > and ofcourse the msx audio music chip. > but when your msx already has an expanded bios ( maybe the rs232 , there is a lot > inside the G900P) > you can get problems. > maybe you can try to poke &hFFCA , 00 , and &hFFCB, &hC9 (nop and ret) > > Erik de Boer > This sound logical But if the whole point is that there is something on this hook, why not test that first, do this POKE if it's empty, and do nothing when there's already something there? In other words, replace: POKE -54,35 with: IF PEEK(-54)=&HC9 THEN POKE -53,&HC9: POKE -54,35 (If there's any other IF's before that: just leave those). So, Manuel, try this now, and then stop filling our e-mail boxes with this nonsens, ok? Greetings, Alwin ([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/)
uploaded Split v1.1 (file spitter)
Hi all, Quickly after my previous upload, I again uploaded a utilitly I wrote once. It's called "Split" (v1.1), which is a file splitter, that you can use for example to split MegaROM files into single blocks, or easily strip some kind of header of a file. How you determine what files to break into pieces and exactly where, is up to you, there's no file searching or -viewing options in it. But it has almost every thinkable option of how you want files to be divided in smaller pieces. Only 'shortcoming': it needs MSX-DOS 2. So, if you need such a program for some purpose, you can get the ULTIMATE tool for this 'simple' task at: http://huizen.dds.nl/~alwinh/msx MSX Tech Doc page Greetings, Alwin Henseler([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: MSX1 -MSX2 compatibility
Hi, Stefano Fronteddu <[EMAIL PROTECTED]> wrote: > A lot of You know that MAIN ROM slot's identificator is located at > 0FCC1H. > In MSX2 the MAIN ROM can be in any slot, while in MSX1 it's in slot > 0 or slot 0-0. Why is there this difference ? No, that's for MSX2 Sub-ROM. Main ROM has to be in slot 0 or 0-0, as for MSX-1. > Is it wrong to call Basic using 80H as slot identifier ? Yep, for 2 reasons: -It tells the MSX to switch secondary slots 0-x, which there are not if (FCC1h) was 0. This also messes up memory location h here, which it SHOULD not (and will not, if called correctly) -It makes the MSX do a lot of unnecessary extra work if slot 0 wasn't expanded, as is the case on many MSX's. > I know that the following code works well in both MSX type > > LD A,(0FCC1H) > LD H,40H > CALL ENASLT So why not use this correct way then? Replacing "LD A,(FCC1h)" with "LD A,80h" saves 1 byte of code, and a TINY amount of CPU time on some machines, wastes a lot of CPU work on many other machines, and (strictly speaking) makes your program non MSX-compatible. So on average, the above way works both better and faster, and I couldn't think of ANY reason not to use this. 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: Partition table format
Hi you all, Nestor Soriano <[EMAIL PROTECTED]> escreveuz... > >So if we will make some fat16-formattingprogram, we will have to format in > >MS-DOS 4 way. > > It is the best idea I think. "MS-DOS 4 way" means extra information in the > boot sector: > > #20-#23: Number of sectors if it don't fits in 16 bits (else, this number > is placed in #13 as in older versions) > #24: Number of physical unit for HD (#80 is first) > #25: Reserved (normally 0) > #26: #29 > #27-#2A: Serial number > #2B-#35: Disk name or NO NAME > #36: FAT12 or FAT16 string > > The problem is that MSX-DOS puts a booting program starting in #20, so > disks formatted in this way can't be used for boot. No sweat! Older disk format only fills parameters up to offset 1C-1Dh (=number of reserved sectors), MSX bootsector routine starts at 1Eh, and the above starts at 20h, which leaves 2 bytes (at 1E-1Fh), just enough to put in a JR-instruction to a bit further on. MSX-DOS2 formatted disks already do it that way... Do note though, that on bootup, only one half of the bootsector (offset 0-FFh, 256 bytes) is copied to C000h before C01Eh is called, making it a bit difficult to use the other half for boot code. 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: Hardware schematics
Hi all, Hans Korving <[EMAIL PROTECTED]> wrote: > I already posted a message like this on comp.sys.msx, but got no answer:( > > I'm looking for schematics/diagrams for homemade MSX hardware. > If possible using old/spare MSX parts. > > I'm looking for schematics to add more memory (on a NMS8250) intern or extern. > Also fun, would be a cartridge expander. > I'm also looking for schematics to put on my homepage. Check out my pages: -MSX Super Turbo (my own design, a la 7 MHz., and above) -MSX Audio 256K sampleRAM connections Maybe I'll put some memory mapper circuit diagrams up there some time, but I'm not in a hurry with that (sorry) ;-( Anyway, you can find lots of schematics for MSX hardware in old books and magazines, like: -MSX MegaMapper (MK mapper 1/2/4 MB.) in MCM #6x I think -joystick switch / autofire -7 MHz. etc. And some Russians put online a description of how you can build a HD interface. Many of these are free to publish elsewhere, or no-one cares anyway...just let us know when you put something on the web that wasn't to be found there before, ok? 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: Anti-virus
Hi, Adriano Camargo Rodrigues da Cunha <[EMAIL PROTECTED]> wrote: > Someone knows if exists an anti-virus for that hating "Do you know > today is ZAPP's birthday?" virus? If it doesn't exist, I'll have to > create one... 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. Butteehh, Mh more interesting than that antivirus is that virus, I think! I heard of a 'Zapp' virus several years ago, and ofcourse several 'antibiotics' were produced quickly. But I never saw that Zapp-virus itself. And ofcourse, after the spread of these antibiotics, it was nowhere to be found anymore. ;-( 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). BTW. does anyone know where this Zapp-virus came from, who wrote it originally, or if there are any other virusses or alike on MSX? 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: diskROMs/page 1 loading
Hi, Laurens Holst <[EMAIL PROTECTED]> wrote: > :> What might be an interesting spin-off is whether loading in page 1 > :> is legal or not. > : > :Absolutely legal. Supported by DOS1 (& DOS2 in other ways) with > :various help-routines, and supported by every > :(DOS1-compatible, used for SS/DS floppies) diskROM that I have come > :across. If it wasn't legal to do this, I'm sure it wouldn't be so > :generally supported, so sure this is okay. > > Ummm... reaction on a message posted some time ago: > > In Dos, loading in page 1 is ok. However, in Basic, loading in page 1 can, > and will, corrupt the data. This is because the diskrom is swapped into page > one. > > So, in Basic, you can't load into page 1. In BASIC, you have the BASIC ROM in page 1, right? So how are you gonna read data from disk in there? If you have started a program from BASIC, and switched RAM into page 1, reading/writing data in there goes FINE, provided you indicate in system variable (F342h) (DOS RAMslot for page 1) the RAM slot currently selected in page 1. Note for programmers: save this variable before changing it, set it, do your thing, and restore as it was afterwards... If you want to know how it works: get out a good debugger, and simply trace a disk-call, and see what amount of trouble is gone through to get the data where you wanted it... As explained earlier, this all works a -bit- (?) different under DOS2... > This is because the diskrom is swapped into page one. Happens just the same under DOS as well... 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: Mailinglist..
Bilderbeek J <[EMAIL PROTECTED]> wrote: > Just a question: does anyone know how to start up a Mailinglist (no > I don't want to start another MSX list...) It is simple: a) Tell possible subscribers what this mailing-list is, or what it's about, how to subscribe/unsubscribe b) For anyone telling you he/she wants to subscribe to the list, add his/her e-mail address to your list (=the mailing-list) c) For anyone telling you he/she wants to unsubscribe, check if their e-mail address is on your list, and if so, remove it again d) For any messages that need to be 'posted' on this mailing-list, send an e-mail with this message to the e-mail addresses on your list (=the mailing-list) e) If this gets too much work, use a computer to do the dirty work. That's it! 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: Philips VY-0010 diskdrive
Hi Manuel, and other interested parties: Manuel Bilderbeek <[EMAIL PROTECTED]> had this problem: > I have a question about the Philips VY-0010 diskdrive. I recentely got one > (for free! ;-), and when I made all the connections and switched everything > on, the power LED went on, and after 2 seconds, it went off again... > (...) > programs from disk. But one strange thing is happening: when I don't put a > disk in the drive, the drive tries reading. You can hear it spinning and you > hear the drivehead moving. Also the BUSY LED is lit. But it won't stop! I > should get a "Disk offline" error, shouldn't I? But the computer waits and > waits... Only when I turn off the drive, the computer reports "Disk offline". > When I then insert a disk, I can use it normally. But this whole thing is > rather irritating! I now cannot boot without a disk in the drive... (unless I > turn the drive off...) I know of something about these antique diskdrives, that might be the solution here: I had one myself for a while, and it worked incredibly slow (fast compared with tape, but really slow compared with other disk interfaces). When booting, it seemed to expect a disk in the drive (better to put that disk in after power-on, instead of powering on with the disk inside). It tried to read this disk, and if it wasn't there, made a scratching noise (disk head movement), and again, and again, and again, and again (didn't sound to healthy for the diskdrive either), and only 'gave up' after a really long wait, something like a half minute. For starters: maybe you didn't wait long enough yet, try and see what happens if you give the thing all the time, and I expect you will wind up in MSX-BASIC after all, without a disk in it, if you have enough patience. This problem is simply the result of a very old diskROM in the disk-interface. If you plan on going to use that drive more regularly, than it would be a good idea to replace it with another diskROM. You can use one from a NMS8250 or Sony 700 MSX-2, or use one from a NMS8245, in which case you should ground pin 34 of the floppy-connector (=disable ready-signal) to make this one work correctly. You can skip that last part if you use that 8250/55/80 or Sony 700 diskROM. The interface will think it's double-sided after that, even though it isn't, but if you ignore that it'll work at lot better that way. Unfortunately, you can't take the interface itself as a general-purpose disk-interface, because although it looks like a floppy-connector on the interface part, it is not. With this thing, part of the electronics is in the interface, a number of signals get carried to the drive housing, where another part of the electronics resides. Only way to hook up other drives therefore, is to connect these directly to the signals in this drive housing (I think it used another type of connector as well), and I'm not sure whether it could support DS drives either. As before, consider it antique (amazing if it is still in original state and works 100%, it'll be something like 14-15 years old by now). 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: MSX-PC GFX converter
Hi, IVAN ALONSO BES <[EMAIL PROTECTED]> typed in: > I'm looking for a good MSX gfx viewer and converter for PC, I mean > any kind of tool that could allow me to transfer screen5, 8..12 gfx > to Pc and also Gif or Jpeg to MSX formats. As far as I haven't got a > harddisk for the MSX I need a PC version to test different ways t > oexport GFX from photoshop or 3dMAX t othe MSX. I'd very pleased if > someone could help me to find a link where I could get this soft. > Bye For MSX -> PC: Rudolf Lechleitner, author of RuMSX emulator, also wrote a set of MSX-screen viewers. So, you can simply copy your BSAVE'd MSX-screens to the PC, and view them with these (several screens, including 8 & 12, supported). These Windows-utillities allow direct saving as BMP-files, which can be processed into other formats easily. Last time I looked, his MSX-pages were at: http://members.ping.at/lexlechz/msx.html Another way would be to load the pictures on an emulated MSX, and then use the screendump function found in many (not all) emulators, dumping the MSX screen in .BMP, .PCX format or such. Although you have to watch that not all MSX resolutions (512 pixel width!) or color depths (MSX2+ screens) are supported that way. But usefull for screen modes like 5 & 8. 3rd way would be to use the MSX itself to write an MSX screen to disk in a format like GIF or BMP. I know of at least one GIF encoder for MSX, and a TSR, that -would- (didn't test it) write a MSX screen to disk in BMP format. For the PC -> MSX: Use a GIF (up to 256 colors) or JPEG (more colors) viewer for MSX, that has an option to save the screen in 'native' MSX format. One thing that would be very usefull here: use the PC to process (resize/color depth adjustments) the pictures so, that they have a 'convenient' combination of colors/pixel sizes, giving an MSX viewer an easy task of selecting a suitable screen mode. (like 256 x 212 x 256 colors, or 512 x 212 x 16 colors). All this is for the most part not too difficult, just a lot of work. I suggest doing any image processing on the PC as much as possible, many MSX programs have very limited capabilities or bugs in this respect, and take much more time for it. BTW. What has the presence of a MSX harddisk to do with this? As far as I know, such tools can normally work with any type of disk (like 720K DD disks). 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: NEWS TILBURG 1999
Need a translation? Okay... From: Computer Gebruikers vereniging <[EMAIL PROTECTED]> TILBURG 1999 is ON About: Tilburg 1999 ! Sorry for not reacting earlier, but here is the current status about the Tilburg 1999 fair ! The reason behind the "silence" is not a lack of interest on our part, on the contrary, but because of posponing the decision in the hope we could go on as before. It looks like we will not be able to organise this fair in its former size. This does NOT mean that Tilburg 1999 will be cancelled !!! Let's make some things clear... Up till now (december 15) there have only been 18 places reserved by standholders. When we fill 4 stands ourselves, that gets us to 22... It is so that the Bremhorsthal (note: name of the usual location) is only reasonably filled when occupied with some 60 to 70 stands. With this number of reservations we can and will surely not use the Bremhorsthal. Ofcourse there are still reservations coming in, but the difference between now (22 stands) and the needed number of 60 is just too big. We feel it is not right to receive the public in a large hall where the standholders occupy a single corner. This would not do justice to the MSX. Apart from that, the rent for the Bremhorsthal including stands, electricity, furniture, etc. is fairly high (4000 to 5000 Dutch guilders). We expect that because of the falling away of the MCCM, the magazine that was of great importance for us for informing the target audience, the number of visitors will surely decrease. It is ofcourse always fun to meet each other again, but chances are it would become a very costly meeting for us. I would like to ask you to be patient for a couple of more days, as we are negotiating for a different location ! There will be a somewhat different setup then. WE WANT TO ORGANISE A BIG MSX MEETING THEN in a local community center. The cost will then be low for the participants (30 Dutch guilders per 3 meters table, including 3 standholder-tickets) and a low entrance fee (2,50 Dutch guilders) for the visitors. For now, we are still planning for the same date (remark: which would be?) It is still of great importance that we can count on a sufficient number of participants, and that you promote this day and make it known to all interested parties ! SO STOP THESE NEGATIVE MESSAGES AND MAKE SURE EVERYONE COMES TO TILBURG DO LET US KNOW WHO WILL BE JOINING THIS DAY So don't pospone and let us know quickly by a mail if you want to come (also if you registered before. We will ofcourse need to know if you will also be joining in this changed setup...) We will then inform you as soon as possible at what location the MSX-MEETING will be held. So quickly send your response to: [EMAIL PROTECTED] or send a fax to: 013 - 4560668 or call us at: 013-4560668 or 013-4681421 (after 19.00 hours) (remark: phone numbers as when called from within the Netherlands) We're counting on you ! 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/)
Re: MONITOR PHILIPS AND TURBO R
Hi all ! Maarten ter Huurne <[EMAIL PROTECTED]> replied: > >I need to make a lead Turbo R to Scart connector, who can send me the > >wiring diagrams or better, who can make this lead for me?. > > Turbo R DIN RGB plug: (seen from cable side) > Note: this is the same as SONY HB700 RGB plug > > 7 6 > > 381 > > 5 4 > 2 > > Pin: Description: > 1ground > 2audio > 3status composite > 4composite > 5status RGB > 6red > 7green > 8blue > Not quite correct ! The layout of the pin numbers on the plug is, but you mixed up a couple of signals. Correct layout for the Turbo-R RGB connector (8-p. DIN) would be: 1 ground to SCART pins 4, 5, 9, 13, 14 & 18 2 audio to SCART pins 2 & 6 3 status RGB to SCART pin 8 4 composite video to SCART pin 20 5 Ys (luminance) to SCART pin 16 6 red to SCART pin 15 7 greento SCART pin 11 8 blue to SCART pin 7 You can use a connecting lead made like this for the Turbo-R, Sony HB-F700, and Sanyo Wavy MSX2+ as well. The signal on pin 3 (status RGB) functions like a switch signal, where any voltage from +3 to +12 volt signals 'on', and anything below that indicates 'off'. This is for instance used if you're connecting your computer to a TV with SCART input. In that case, the TV will automaticly switch to display of the RGB (SCART) signal when the computer is turned on. It is usually connected to +12V (sometimes only some 5V, but this should work the same) through some series resistor. The Sony F700 and Sanyo Wavy only put a composite sync signal (no complete video, only synchronisation signals) on pin 4, where the Turbo-R seems to put a complete composite video signal on this pin. An RGB monitor only uses this to extract the synchronisation signals, and therefore either composite sync, or composite video will do. The signal on pin 5 (Ys, or luminance) is not really a signal, but carries a constant voltage of some 3 to 4 volts. Some monitors seem to need this though. Although most or all of the ground pins on a SCART connector are usually directly connected on the monitor side, it is good practice to connect all ground pins of signals used in the SCART plug, in case they're not. The audio signal should be connected to both left & right audio inputs on the SCART plug (as above). If not, you might get the sound from only one speaker (or no sound at all?). > To Manuel Bilderbeek: Is this info already in the FAQ? If not, please add it. To Manuel Bilderbeek: Is this info correct in your MSX FAQ? If not, please correct it. If yes: well done! 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/)
ZIP/UNZIP source code
Hi, About these compression methods: It's too bad that (to my knowledge) there's not a single compression method for MSX machines, for which: a) Both compressor and de-compressor exist b) Which are essentially bug-free c) Can handle about every (un)packing job PMA: PMarc sometimes produces .PMA files which produce checksum errors on unpacking, even though they're freshly packed (!), and both PMarc & Pmext round up file sizes to multiples of 128 bytes (due to their CP/M origin). Mostly not that big a problem, but not quite correct, and does cause problems in some cases. And...using .PMA files on PC's is very difficult. LHA: I'd say the best (un)packing method that exists for the MSX today, butalso has a bug: if files to be (un)packed get really big (> 1MB or so), packer or unpacker screws up (Can someone fix this bug?) ARJ: There does exists an ARJ unpacker for MSX, butno packing program. ZIP: Yes! Forget about packing, but it sure would be nice if someone would write a -decent- ZIP unpacking program for the MSX. Say, PKZIP 2.04 compatible, and with support for unpacking directory trees stored in ZIP's. For this purpose: There exists something called the Info-ZIP group, which is kind of a 'collective' (hobbyists like most of you) that maintains a freely distributable ZIP packer/unpacker. Goal of this group is to have a free ZIP (un)packer on as many different systems/platforms as possible (existing versions support all current ZIP features). I don't know an exact web-address where this can be found, but: both the ZIP packer, unpacker, and ALL source-code should be available on SimTel. I guess you should be able to find that. (look in the DOS collection, and maybe in some "programming" directory). Maybe sometime the MSX system can be added to the list of supported platforms? AND YES: CAN YOU STUPIDS STOP MESSING UP THIS MAILINGLIST WITH THAT NONSENSE ??!!! You're right, it's okay to have fun, and yes, MSX is about having fun with it, but: If you couple of &%(#'s (cheese-heads?) send 50 e-mails back and forth with pure nonsense in it, and this mailing-list has, say 100 subscribers, then you've just pumped 5000 totally, absolutely unnecessary e-mails through the net, produced MB.'s of totally, absolutely unnecesary, and avoidable network traffic, and... Bothered every subscriber to this list with 50 e-mails they have to read, and hit a delete key for one by one, after which they have learnedNOTHING Thanks, but no thanks, cut it out! I greet you, 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: PSG
Hi, shevek <[EMAIL PROTECTED]> was asking about the PSG: > Last week, I wrote about MSX PSG accessing. On Commodore 64, it is > impossible to read sound registers, so when I saw the same in MSX BASIC, I > thought it was a hardware thing. No, on the MSX you can both read & write PSG registers, both through hardware & BIOS as well. > I never tried to write to register 14, but if it is not hazardous, that is > only good. Sure you can't destroy MSX hardware by a simple programming trick! (prove me wrong) > In the tables I have at home, register 7, bit 6 and 7 are said to be port > A/port B, and register 14 bit 6:keyboard. Does anybody know what those > bits do? You asked something like this earlier. I suggest you get some GOOD documentation on MSX stuff. I can recommend the Dutch "MSX-Handboek voor gevorderden", which gives a detailed explanation of MSX hardware use, nicely combined with the info on support by BIOS routines or MSX BASIC. The MSX Technical Databook is also a very good reference (if you can get your hands on a copy). And ofcourse there is the MSX2 Technical Handbook, which Nestor Soriano put online. PSG-registers 14 & 15 reflect the general-purpose I/O-ports included in the PSG, in the MSX these are mainly used to control the 2 joystick-ports. Bit 6 & 7 of PSG reg.7 determine wheter these PSG ports are read-only, or can be used as output. Bit 6 controls this for port A (PSG reg.14) and bit 7 controls this for port B (PSG reg. 15). In the MSX, the use of these ports is fixed: port A = input (bit 6 of PSG reg. 7 = 0) port B = output (bit 7 of PSG reg. 7 = 1) Therefore, either changing these bits has no use, or it can be that these are hardwired this way (if the PSG is integrated in some type of MSX-engine). Bit 6 of PSG reg. 14 (=port A, input) is used in Japanese machines, and indicates a type of keyboard layout. I quote from the MSX Technical Databook: JIS layout - "H", syllable layout - "L" Don't ask me what it means exactly, although I do suspect it's something different than the keyboard layout as indicated by ID-bits in the MSX ROM. I expect this bit will always read as "0" on non-japanese MSX machines, and will either read always "1", or indicate some state related to the keyboard, in Japanese MSX machines. Similarly, bit 7 of PSG-register 15 (port B, =output) controls the Kana LED in Japanese MSX machines (0 = on, 1 = off), but has no effect on non-Japanese machines. 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: diskROMs/page 1 loading
Hi, A little spin-off here, about details of how diskROMs load sectors in page 1... Maarten ter Huurne <[EMAIL PROTECTED]> wrote: > What might be an interesting spin-off is whether loading in page 1 > is legal or not. Absolutely legal. Supported by DOS1 (& DOS2 in other ways) with various help-routines, and supported by every (DOS1-compatible, used for SS/DS floppies) diskROM that I have come across. If it wasn't legal to do this, I'm sure it wouldn't be so generally supported, so sure this is okay. > I have been disassembling the NMS8250 diskROM and I > found a routine that runs in page 2 (!) and reads a sector. The only > reason for such a routine would be to load data into page 1. Quite possible (as described in my earlier message) > Did the > implementors of that diskROM do something that was not necessary? Is > it left-over code that is never actually called? Not unnecessary here. It is however quite possible that you come across some 'dead code' (not used, but still there) in diskROMs. Apparantly diskROMs are pieces of code, which between models & hardware revisions, were updated far more frequent than other system software, so there are many different ones, some with several bugs or lousy programming work in it etc. So some dead code in there is really not unusual. In the NMS8245 diskROM I disassembled once (it's on my webpages), the disk-I/O write verification (controlled by DOS verify on/off, using a flag at F30Dh) was hard-coded as 'off', no verification on write actions, no matter what this flag says. But the code for using that flag, and writing sectors WITH verification, was still in there. After making this disassembly, changing one or two single instructions was enough to re-enable support for this verify-flag. And working perfectly. As before: really not uncommon such things. > Or is loading to page 1 by the #4010 routine legal after all? Dutch: ja dus! ;-) 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: Partition table format
s: even with a 24-bit sector number: would you keep that stored entirely in Z80 registers throughout an important part of your program? I don't think so. You'll probably put that in some memory location anyway. With my method, you can just pass the address of that, and you're done. With the other method, you'd have to fetch this number, and store it elsewhere before each DISKIO-call. > The other parameters: Carry for write/read, HL=DTA B=#sectors C=mediaID > > Question: does someone know if the output of the function is specified?? I > know of Carry and A-register for indicating errors. But I've read > somewhere also B-register for indicating the 'amount of read sectors'??? > Is this true? (I don't think so) I quote from the MSX Technical Databook: Outputs: If successfull, carry flag cleared Otherwise, carry flag set, A = error code (0, 2, ..., 12, some more codes for DOS2) B = number of remaining sectors And this number of remaining sectors is actually returned in practice, although this is used seldom by programs. (equal to input number if nothing could be done) BTW. the number of sectors is defined as 1...255, and it may actually be 255 (!), because for MSX-DOS 1, the sector size need not be 512, but can be smaller or bigger, like 128, 256 or 1024 bytes. So it's perfectly possible that some old DOS1-compatible driver could be passed 255 sectors to read/write, if it would use a 128 byte sector size (some 32 KB. this would be). Ofcourse most interfaces use only 512 byte sector size, and this was fixed for DOS2, I think. I'm not sure about 0 sectors, although 'illegal', should this be read as 256 (most likely crashing the machine), or as 'do nothing'? Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwin/msx (MSX Tech Doc page) HelpPC 2.10 Quick Reference Utility Copyright 1991 David Jurgens Boot Sector (since DOS 2.0) Offset Size Description 00 3bytes jump to executable code 03 8bytes OEM name and version 0B word bytes per sector 0D byte sectors per cluster (allocation unit size) 0E word number of reserved sectors (starting at 0) 10 byte number of FAT's on disk 11 word number of root directory entries (directory size) 13 word number of total sectors (0 if partition > 32Mb) 15 byte media descriptor byte (see MEDIA DESCRIPTOR) 16 word sectors per FAT 18 word sectors per track (DOS 3.0+) 1A word number of heads (DOS 3.0+) 1C word number of hidden sectors (DOS 3.0+) 20 dword (DOS 4+) number of sectors if offset 13 was 0 24 byte (DOS 4+) physical drive number 25 byte (DOS 4+) reserved 26 byte (DOS 4+) signature byte (29h) 27 dword (DOS 4+) volume serial number 2B 11bytes (DOS 4+) volume label 36 8bytes (DOS 4+) reserved - implementation format not guaranteed in all OEM DOS releases - BIOS expects a boot sector of 512 bytes - DOS 3.2 began reading BIOS Parameter Block (BPB) information from the boot sector, previous versions used only the media byte in FAT - DOS 4.x added offsets 20-3Dh and offset 20h determines the number of sectors if offset 13h is zero - hard disks have a master boot record and partition boot records; the master boot record and Disk Partition Table (DPT) share the same sector HelpPC 2.10 Quick Reference Utility Copyright 1991 David Jurgens FAT - File Allocation Table 12 BitMeaning 16 Bit 000 free space FF1-FF7 bad track marking FFF1-FFF7 FF8-FFE may be used to mark end of a file chain FFF8-FFFE FFF standard marker for end of a file chain - the FAT is implemented as an array containing a linked list for each file; the files directory entry has a pointer to the first cluster which contains the cluster number of the next cluster in the chain until the pointer contained is FFFh (12 bit FAT) and h (16 bit FAT) marking end of file - DOS maintains two copies of the FAT, but does not use the second copy for anything other than a mirror image of the first; CHKDSK doesn't even read the second FAT - disks with FF1h clusters and above use 16 bit FAT tables, disk with less use 12 bit FAT tables - DOS 4.x did
Re: Bigger sector numbers
h work for the makers of DOS2, so the slotswitching was dropped, and only mapper-block switches are needed (apart from slot-switching involved in calling the driver). Because of this, you will see that under DOS2, memory locations F341-F344h always contain the same slot, this will always be a mapper RAM slot, and all disk-I/O will go to this slot, even if other slots are selected when a disk-I/O call is made (try it, and you will see that this is true). This is the reason for many programmer's headaches, when trying to write software that does disk-I/O using multiple RAM/mapper slots, and under DOS2 (like for sampling programs, using MemMan to use 2 or more memory mappers). No problem doing disk-I/O to the 'primary' (DOS-) mapper, no problem accessing the other mappers, but disk-I/O to these other mappers under DOS2 simply doesn't work right, the data always lands in the primairy mapper. 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/)
DOS3 general setup
ces 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 defined for particular SCSI/hardisk/floppy-disk interfaces where possible, or, if the details for a certain type of interface are unknown, it would simply support this anyhow, by 'falling back' to a more general/standard access method, like sector-I/O routines defined in the old system. For instance, if there is documentation on how to directly access SCSI devices using bigger sector numbers, it could do that by calling the specific SCSI BIOS routines defined for that interface, and sorting out the partitioning scheme for itself. If a harddisk-interface can't be determined for sure as a particular type, the more general disk-I/O routines in the interface would be used instead, leaving the separation in partitions up to the software in that harddisk interface. The separation between all these access methods would exist only on the level of the internal file system/sub-driver interface, and each of these 'drivers' would only exist as a piece of source code, used for assembling each version of the final system. If some new device would pop up, a piece of source code could be written implementing one of these file system/sub-driver interfaces, and then assembled together with the rest of the code for the current system. Et voila, a new version, supporting that new device. Users would only know a number of different versions of system files, like a paticular version of (?) 'msxdos3.sys', and the only 'installation' required, would be the selection of a version, in which the hardware they have is supported. Any user configuration could be done through some settings file, where, in the absence of it, carefully selected defaults are used. What would be needed for all this? 2 things: -A definiton of some of these internal interfaces, like a definition of such a file system 'driver' -The sorting out of a lot of technical details, like file systems, partitioning schemes, system variables/DOS calls to support and what exact calling methods to use etc. In this way, the design of a new system, would for the largest part simply come down to sorting out these details. If all is known about what it should do, and how it should do it, actually programming it will finally be peanuts in comparison. Most programmers among you will have to agree, that a lot of programming time is actually spent on figuring out how exactly the program should work. If you know EXACTLY how a program should work (for instance, if you have an example source code written for another system), the actual programming becomes more something like a conversion. Designing a new system this way, has another BIG advantage: ANYONE can join in with this figuring out/thinking process, and in that way, actually do some of the programming, without having to be a programmer. Then, if you would figure out something together, and run into a problem later on that would require re-doing some of the earlier work, that earlier work will not have included any actual coding, and the work to be re-done would simply be an agreement on an alternative method, defined in 'pseudo-code'. All this could speed up the creation of this new system enormously. Frankly, by this time, I have become convinced we're not just brainstorming here, but having an entirely new disk system for the MSX is a VERY REAL possibility. 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: Bigger sector numbers
ber = 1: DE = low 16 bit of sector number (was: sector number) IX = high 16 bit of sector number (was: unused) Other parameters as usual, output as usual How to determine the presence of features As a programmer, you're mostly not interested in system version numbers; you don't really care if it's an MSX-1 or MSX2+, you care what videochip is in there, and if you can use a mapper or not. You don't really care if it's DOS1 or DOS2, you care about being able to use file handles, mapper support routines, or not. For that reason, I propose that any new disk system should report itself as version 2.x, as before, and indicate the presence of new features (FAT16 support, big sector number support, etc.) through a specialised function call. I think function #71 hex would be free for this purpose, and I suggest calling this: 'get feature info'. This would be a general function; for each feature to determine, the programmer would call it with a 'feature-ID' in the A register, if necessary with other input in other registers, and the return parameters would indicate the presence/support of that particular feature, with the exact return info depending on the particular feature. For each feature NOT supported, the return values for both new AND EXISTING systems IS defined as: A=B=0 (probably zero-flag set as well). So it already works that way in DOS1 or DOS2, as it exists now. I would propose these 2 sub-functions here: If called with A=1 (get info on 32-bit sector number support): returns: A=B=0 -> no 32 bit sector number support A<>0 -> 32 bit sector number support for BIOS-routine 0144h / FFA7h hook B<>0 -> 32 bit sector number support for DOS functions 2F/30h In other words, A and B would serve as flags, where A would indicate 32-bit sector number support for the BIOS-routine, B would indicate this for the DOS functions. I think it's usefull to indicate this separately, this would allow to implement it seperately. If you implement both, you can set both flags. If a programmer needs both, he/she can simple OR these flags together. If called with A=2 (get info on FAT16 support): returns: A=0: no FAT16 support A<>0: FAT16 supported Any extra info to be determined later, if necessary If called with any other value for A then 1 or 2, this function would return A=B=0 (let's leave A=0 for input alone, shall we? It's sort of a magic number...) 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. If you would use some special ROM memory location, which location to use then? If you would use a new entry, how to fit this in existing ROM's? Using a special sub-function for 4010h entry could have an undesirable impact on performance. I'm sure we can find some special calling sequence to put into one of the other entries, that will do fine. 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: Bigger sector numbers
ble 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 could even use the DSKIO-entry itself for this, no impact on performance, and very little extra bytes to be added, very easy to implement. I think a 2 or 3-byte signature would do, maybe followed (damn no! preceeded!) by a 'feature flag byte', version number or such. Checking it would work as follows then: Get byte at address #4010 =C3h (jump?) If not, no 32 bit sector number support by this driver If yes, take address of the jump Lower this address by 2 or 3 Signature at this address? If no, no 32 bit sector number support by this driver If yes, 32 bit sector numbers supported, extra info might be found at this address -1, -2 etc. Why use a new DOS function for indicating the presence of these new features? I think the main advantage of using a DOS call is 2-fold: -Easy for programmers, call it just like any other DOS function -Reliable; if you use Extended Bios-hook for it, you might get incorrect results if some program modified this hook in a not-so-neat manner, if you use a couple of flag bytes at fixed memory locations, these might be corrupted by not-so-neat working programs. DOS functions generally don't suffer from that. It need not take up any page-3 memory space, and calls could work fast (not that it matters for this purpose). By the way, re-routing calls to DOS entries at both F37Dh and 0005h is not really that difficult. Entry F37Dh can be re-routed without any problem AFAIK, the same goes for DOS-entry 0005h. There are some conditions to watch here, like the fact that the address of this 0005h-jump also indicates the free DOS memory. There might be some other system variables using this/ used to set this as well. One way or the other, this can be done, I did it myself sometime. I don't know exactly how anymore, but this really is not that difficult. 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: 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 FFA7h<>C9h). 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) "unsu
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: 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: 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/)
TP 3.3 / MCCE copyright issues
7;can't do'. The main argument against it was this: if you sold it to a number of people for xx bucks, how are they gonna feel if you put it on a website to get for free, some time after. How would people feel who once bought Konami's Salamander for say, 50 bucks, and Konami would put it on their website a year later? I think this is mainly a matter of time. The longer you wait between the last time you sold it, and a moment you would make it freely available, the less buyers of an original would feel offended by that. However, I am very curious on your view on this argument. So please let us (or me personally) know: if you bought some Konami ROMs once (or other software) for 'big bucks', how would you feel if they opened up an FTP-site now, with all these ROMs to get for free, themselves? Would you think: "damn, I hate'm for doing that", or would you say: "nice, to see them showing of those oldies" ? I hope this clears the 'legal issues' here. For any questions related to these things, please read the documentation first. If that states an address, or bank account number where you can put your donations, please use that. If not, it's okay to ask me about it. Both Herman Post and Frits Hilderink didn't mind if I would handle that for them, and I'll see to it that they will get any gifts or postcards, if you send those to me. For Turbo Pascal 3.3, only bug reports ARE taken. If you happen to find a bug in the compiler, the maker of it would still like to know that. However, there's no guarantee he (we) will do anything with it. If you happen to find a bug, please send your (Pascal) program that shows this bug, preferrably with the sources, not only a compiled version, along with all the things YOU used to produce this bug, so the DOS system files, Memman binairies, GIOS etc. etc. YOU used, that lets this bug show up. It would be preferred if you could make your program just small enough so that it will show this bug when compiled, and remove everything that doesn't affect it. All this would make it easier for us to reproduce or find that bug. Frits Hilderink said it would be okay to send such requests to me, so that I can filter these, and only need to bother him with a real bug, not with any 'minor' requests you might have. Maybe you can even exactly locate such a bug yourself, which ofcourse would save us a lot of trouble, improving chances for an update. Note: this only applies to bugs IN THE COMPILER, so in case your program was compiled incorrectly. For bugs in your programs itself, you'll have to ask someone else or figure these out yourself. One final note: Following the above, I think it's okay to put Minesweeper, Tetravex or Logi-Bal on any site, as long as you keep all files intact. For Turbo Pascal 3.3 or Age8, this would be illegal. Personally, I would like to see it otherwise, but I just don't have the final word about these programs. For the most part, copyrights are clearly stated in the programs or documentation itself, and still valid. You will also understand, that we don't have the time or means, or are willing to search the web for any illegal copies, or send lawyers after you (we probably wouldn't even want to). So you have probably nothing to fear, but whether or not you choose to violate any existing copyrights, is your own decision, I didn't tell you that's okay, nor will I try to keep you from doing so. For these copyrighted things, this is just the same as with Konami's or any other copyrighted software (we've had this discussion already, I believe). Greetings, Alwin Henseler Oldenzaalsestraat 116 7514 DS Enschede the Netherlands http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page) e-mail: [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: Bigger sector numbers
Hi again (we keep trying), > > My idea: why not indicate a big sector number with the highest bit of > > the drive number (passed with A register)? (chop, chop...) New calling convention: (drive numbers: for BIOS-routine 0144h: 0=A, 1=B, etc., for driver entry 4010h: drivenumber = 'local' drive) For the programmer: - 'old' disk-I/O: as normal - 'Big disk-I/O': LD A,drivenumber SET 7,A LD DE,pointer to 32-bit sectornumber CALL DSKIO (other parameters as usual) The pointer simply points somewhere in memory. Although diskROM is switched into 4000-7FFFh during the call, I think this pointer can point anywhere. For the BIOS-routine (0144 or FFA7h), DOS can copy the contents at the pointer address to an internal save address (in page 3-workspace, for example). For calls from disk-system to driver via 4010h, this pointer will already point somewhere else. If diskROM is directly called at 4010h by an old program, pointer will be 16-bit sector-number, and things will work as usual. If called for 'Big I/O' directly from a (new) non-standard-obeying proggie, only problem will occur if pointer address is in 4000-7FFF range, but is no problem either, because this would be -illegal- (directly calling 4010h for 'Big I/O', that is) For the DSKIO entry (4010h) in the driver ROM: (check read or write) Bit 7 of A register: if 0, higher bits of sector number = 0, or other 'base' lower bits are in DE register if 1, memory address (DE) contains big sector number (treat equally from here) For those of you who worry about performance: Suppose you need an extra of say, 20 Z80-instructions, with an average time-consumption of say, 10 clockcycles, that would take about 200/3.58e6 is about 0,06 milliseconds (@3.58 MHz). (there go these 10 milliseconds access times...) So don't complain about this, any single interslot-call consumes a big multiple of that. With an extremely fast driver (like one using a HDD with read-ahead cache memory), this could even allow sector-reading from an interrupt-routine (!!) Probably not allowed, but this calling method method wouldn't stand in the way. So, this calling method is: -100% Compatible: if you call an old driver with it, nothing will happen, and an error gets returned. Any old calling methods have the normal effect -'Interslot-call proof' -Fast -Easy for programmers I challenge you to come up with a better way. 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: JoyNet serial transfer routines
sic module (or separate cartridge): just send a byte once, in 1 programming action, and without any software interference, it gets sent to any other receiver connected to the MIDI-out, with little delay. For data-transfer, I would rather make a 'dedicated' cable, optimised for either speed, simple construction (largely 1:1 connection) or as few wires as possible. BTW: I checked the 'official' JoyNet pages, and although I doubt the practical use of defining such a standard, especially when it only defines the cable (that is the simple part, anyone can do that), from a hardware point of view, I'd say there's no problem with what's on those webpages now. Connecting the signals as shown, shouldn't cause any hardware parts to burn, regardless of what programmers do. 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/)
DOS1 diskROM disassembly
Hi, Upon your request, I have added a partial disassembly of a DOS1 diskROM to my webpages. Just visit my pages (address on the bottom), and click on the 'documentation' icon. It also contains a FULL disassembly of the driver part of this diskROM. This part you can re-arrange to your likings (within certain constraints, such as available memory size, or the order/size of SOME small parts in it), but as long as its function is kept intact, it can be assembled, and made into a working diskROM again, I did it numerous times (how-to included). Comments in the listings are in Dutch. Sorry, but I don't think I'll translate it, too much work. If you have any comments, additions or such, I think most of these are best 'dropped' on this mailing-list, rather than directed to me personally, because it seems to interest quite a lot of people. Feel free to upload it to an FTP-site (Funet for example). Please let me know where it's at, if you make a copy available somewhere. 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/)
DOS2+, FAT16 etc.
ge these, any calls to disk-I/O will then automaticly be in the first 32 Meg, if it wants to access anything beyond that, it has to set this BEFORE every call to disk-I/O. This has a big advantage: you could define quite large sector numbers. If programs use only smaller disks, they only have to keep track of the number of bits they actually use, the higher bits are automaticly set to 0 by the system between disk-I/O calls. For sectornumbers: I don't like adding small pieces, if you change something because it became too small, make it a whole lot bigger right away, don't mess with a few bits extra. Frankly, I find the maximum number of drives not really a problem, I have no more than 5 drives in my PC as well: A: floppy drive B: virtual second floppy drive (what's it do anyway, I never use it) C: 1 Gig. HDD D: another HDD E: CD-ROM I wouldn't like messing with 20 drives on a MSX, to allow direct access to bigger sizes. So the problem is not this number of drives, but the maximum size per drive. FAT16 support would be nice, but it's really useless without access to bigger drives, so shall we figure that out first? I have one question here: can anyone make it clear what exactly those special values for cluster numbers (FFx for FAT12, and ??? for FAT16) are, and what they mean? Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page) ** Solve all your smaller problems first, then your bigger problems will turn out to be not so big after all *** 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
Hi again, It was written: >> 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? Doesn't work for me either, because I don't (yet) have direct FTP access... ;-( The JPEG file format is in fact 2 things: -The JPEG compression method -The .JPG/JPEG/JFIF file format The JPEG compression method is standardised in some ISO standard (ISO/IEC 10918 part 1), but: you can -order- this for $$$..., it's not (officially) on the web. But do some looking around, and you might find some pirate copies out there. For these kind of things I consider that a good thing, it's ridiculous that first a lot of people & companies get together to develop such standards for the 'common good', after which some standard organisation like ISO goes out and sells copies of the final documents for xx $$$ a piece. So I really don't mind if some people stick some 'unofficial' copies of such things on their webpages BTW. the compression method itself is free to use, just this ISO document specifying it is copyrighted. Only this ISO standard didn't specify an actual file format (!), just the compression method. Some company (C-Cube microsystems, www.c-cube.com, don't bother looking there) defined the JFIF file format, which does define the file format, and is a 'basic' application of this JPEG compression method. This file format is what's been used for most actual .JPG files. What should be easy to obtain: -This JFIF file format specification -Sample compression/decompression source codes Some links: http://www.jpeg.org JPEG home page not much here but some usefull links http://www.w3.org/Graphics/JPEG/jfif.txtJFIF 1.02 spec's http://ftp.sunet.se/pub/simtelnet/msdos/graphics/jpegsr6b.zip sample JPEG compression/decompression source codes, from the Independent JPEG Group (www.ijg.org) Well, that's the easy part. I think for JPEG, the file format would be easy. The (de)compression method is the hard part, cmmplicated & CPU-intensive (good luck). P.S. Who not do a PNG (Portable Network Graphics, the 'GIF-replacement-to-be') encoder/decoder instead? 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: IDE HDDs formated in MSX
Giovanni dos Reis Nunes <[EMAIL PROTECTED]> wrote: > How I can read, using a PC, one Harddisk formated in a > MSX with IDE interface? I receibe a old Conner 20Mb HD > but I can't read it in DOS or Linux. All Linux and DOS > FDISK utilities shows a "20Mb FAT <32M" partition but > in DOS I always receive the 'Sector not found' error > message. I'm thinking that this HD isn't a formated > partition... Or I'll format this drive. :) 20 Mb.yep, that IS old ;-( AFAIK, this is a software issue, having to do with with the exakt formats used when initialising/partioning the HDD's. Not being able to recognise a HDD partition's contents on an other system, means to me, that either of both used an incompatible format. And when I say you could call that format used by PC's the standard, that would mean the format used by MSX harddisk-interfaces (goes for SCSI as well) was incompatible. Damn !%$(@ fools, why create any other format, than the one used on PC HDD's? The way to go here would be to make the partitions using that PC-compatible format, for instance by partitioning the HDD on a PC, and then using a MSX HDD-interface that recognises/can use that format (what interfaces would that be?), or, if necessary, modifying the software in those MSX HDD interfaces so, that they do. Only limitations you have to watch here, are that MSX only supports up to 64K sectors per partition (thus max. 32 MB. per partition with 512 byte sectors), and FAT12 system (I think MS-DOS FDISK makes FAT16 partitions above some 15 MB.) More info, please! 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: MSX in MIR
Laurens Holst <[EMAIL PROTECTED]> wrote:
> : People,
> :
> : I knew this story of a SONY MSX2 in MIR, but anybody has a
> : photography of this conputer in the space station? Anybody
> : know how this computer gone in MIR? How is the function of
> : this computer inside MIR, etc...
> :
> : Will be nice to play SD snatcher in zero gravity... :)
>
> it was in an edition of MCCM... I don't know which one, but if I find it
> I'll post it on funet.
It was MCCM #71 (november '94), page 37, titled "MSX in space"
And yep, it sure looks like a Sony HB-G900(R? ;-) with about equally
big video extension ("videotizer") attached.
It seems it was on German local ("Beierse") television, in something
to do with the fact that 25 years earlier, there was this Apollo
flight to the moon (so that should fix the date to about . (date
of Apollo mission) 1994). Maybe someone living around there in
Germany could call that television station, and get a copy of that
video?
Alwin([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: XRAM
Hi again,
Mark <[EMAIL PROTECTED]>wrote:
> (..)
> As far as I know,
> the only commercial type of memory that keeps its contains, even when the power
> supply is cut off, is FlashRAM. It is used for instance in chipcards etc.
> However, besides FlashRAM, there also other designs of non-volatile memory like
> (..)
Wrong! It's good this fella here did his homework a bit better.
This 'FlashRAM' you mention, IS no Flash-RAM. These chipcards used
as solid-state disk, are either DRAM (mostly temporary use), Flash
EPROM, or battery-backupped SRAM.
The defining difference here is that Flash memory needs to be erased
first, before it can be re-written, and that makes it EPROM memory.
You can't just toggle single bits, like with RAM. In practice, this
is done in 'sectors' (like in xx KB. parts). From the users point
of view, when writing a modified sector to such a solid-state Flash
disk, it might APPEAR as if such a sector was directly overwritten,
but in fact: -the sector might have been written to a different
physical place, erased earlier, or -the (entire!) sector was erased
first, then re-written.
Next to that, Flash (EPROM) memory can only be re-written a limited
number of times. This might as much as 100.000 times, and such
solid-state disks sometimes use sophisticated techniques to
re-arrange sectors, so that if the same area on such a solid-state
disk would be re-written a million times, this might be 'diverted' to
100 different sectors each being re-written 10.000 times. But such a
limit remains.
To overcome this, SRAM becomes the alternative, but needs battery
backup. DRAM might even be used for that, with some extra
refresh-circuitry (might be built in the IC's), and would probably
consume somewhat more power, but that's just practical matters.
All such different types of chipcards might be called differently.
For instance a 'SRAM' card may in fact be DRAM, with self-sustaining
refresh-circuitry, in some low-power arrangement, and...with battery
backup. Or a 'Flash' card might in fact be SRAM, with
very-long-lasting battery, it all comes down to the same thing: in
essence, there simply aren't that many different types of memory, and
as far as I know, Flash-RAM is not among these (prove me wrong).
If you don't agree with this, I suggest you do some reading on actual
existing devices, instead of confusing us all here.
But indeed there are more types of non-volatile memory. I know
another one, maybe 'related' to what you mentioned, called 'bubble
memory'. I don't know what the technical name would be, but that is
how it's called. The idea with this type of memory is this: in a
harddisk/floppy disks, the magnetic areas defining 1's & 0's, reside
on fixed places on a magnetic material, and this material itself is
moved around under some reading/writing circuit.
In 'bubble memory', the magnetic areas containing the 0's and 1's
(the 'bubbles'), are moved instead, so that the reading/writing
hardware can stay in one place, and no parts need to be moving
('solid state'). How this works exactly is a riddle to me, but the
disadvantage of this type of memory was, that the magnetic area's
signalling "1" and "0" needed to be far larger than in the
floppy/harddisk system, making 'bubble memory' large and difficult to
handle devices. That's why they're not, or barely used anymore, only
nice toys for scientists.
There are surely more of such exotic memory types out there, that
grey stuff in our heads would qualify as one...
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: MSX Y2K bug / RP5C01 datasheets
Hi again, > On Thu, 8 Oct 1998, I wrote: > > > As for the significance of a year2k-bug on MSX: I doubt anything much > > will happen as a result of a MSX year2k-bug, simply because MSX's are > > probably used in very few, or non, 'critical' applications. There's > > surely not an airport anywhere that relies on MSX-computers for the NYYRIKKI <[EMAIL PROTECTED]> replied: > > Well... We have here airplane comppany called Finnair. They used to use > Sony HB-G900p. Anyway they didn't controll traffic, but they used these > computers for secury and simulation training (Don't ask me, what that > means, but they said so) Anyway they did not use these computers anymore, > but they still have few ones with HBU-G900p U-MATIC interface, HBI-G900p > videotizer and Video-CD player. I guess that would be an application where a modern 'multimedia' PC would be used instead these days. I guess that would simply be using such a machine as some sort of 'tutor', where a Video-CD (LaserDisc- I think) player that can be hooked up to a HB-G900 (controlled over the built-in RS-232) would show the 'reading material'. Sounds like a typical application for a HB-G900. On that Russian MIR space station: after all the mess they made in there, I'm 100% sure that any Year2K-bugs showing up in there, won't be the reason for that thing coming back down to earth =8-< Anyway, as I wrote earlier, I wasn't really refering to MSX COMPUTERS being used in critical applications, but much more about MSX-like TECHNOLOGY (system software, similar system set-up, use of parts otherwise typically found in MSX systems, etc.). I think many of you are indeed missing the point here, and its significance IS big for sure. It just MIGHT get solved in other ways by the people dealing with such systems, when we wouldn't get ourselves involved. Greetings, Alwin ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msx(MSX Tech Doc page) http://www.twente.nl/~cce/index.htm (computerclub Enschede) P.S. I found datasheets on the RP5C01 clockchip online recently, it seems that Ricoh put it on their website a couple a months ago. Finally some 'hard data' on MSX parts showing up on a manufacturers' websiteI'll include some pointers to it on my pages soon... They had a nice Year2K statement on these parts as well, stating more or less what I observed earlier: Rx5C01 clockchip HAS a 'century-bug', in the year 2000 it just doesn't show 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: HARDWARE PROPOSAL (7MHz related)
al KC megamapper -modify your mapper, to use an other way of generating DRAM control signals (several ways to do this, but might require some research). I have a 'home-built' mapper myself, with 2 DRAMs of 256K x 4 bit each (256 K mapper, thus) which I changed such, that it doesn't need CPU clock either, and works fine on both turbo or 3.58 MHz. -construct a mapper using SRAM, not needing "CPU clock" for any purpose either -Why not fix one of the cartridgeslot clock signals to 3.58 MHz., and the signal on the other cartridgeslot (most MSX's do have 2, don't they?) to "CPU clock". With turbo on, you can put cartridges (un-modified) using "CPU clock" in the one slot, and cartridges (un-modified) using 3.58 MHz. in the other slot. Just try possible combinations of cartridges you have, then decide what signal to put on each cartridgeslot. Cartridges not using either one can be put in both, and with turbo off, it's all the same, and anything should work. -Or use a combination of the above 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: Some questions about MSX hardware...
MSX Year2K bug
people with detailed knowledge on MSX-related issues, in a wide field of interests. My proposal: - Let us set up some kind of 'MSX Year2K Center'. Anybody needing information from some related field, like professionals involved in solving year2k-issues, might be given a valuable source of information with that. For anyone simply interested in it, such a 'MSX Year2K Center' could provide direct answers. This mailing-list might be a good medium for sharing information related to it. If any new problems come up, such a 'MSX Year2K Center' could be the central place to address it, and for any solutions found, or facts determined, it would be the central place to find such facts or solutions. You might not see the possible importance of this, but if anyone should provide some central place for MSX-related year2K issues, shouldn't it be a couple of MSX-freaks like us, running that store? And why would you take part in it? To finally put some of that knowledge to some really important use, or...for the fun of it. 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: Some questions about MSX hardware...
Hi all, Gabriel D. <[EMAIL PROTECTED]> wrote: > SRAM = Static-RAM , doesn't need any power to keep data, but only to change > the stored bit value. I'm sure you can find lot of information about SRAM > (AFAIK called FLASH in some commercial products) functionning. You got some things confused here: SRAM only needs 'ordinary' power when used (reading/writing), and because it's static, 'none' when not used. That 'none' power is only in principle. It does need to keep its supply voltage, and in practice does use SOME current, to keep its contents. Modern SRAM's work near-perfect in this respect, and there are sometimes specially selected/produced low power types. For such a SRAM, a simple battery can maintain a supply voltage for years (like a CR2032 3 Volt Lithium battery), where an important factor becomes the discharging of the battery itself. These days, for some purposes there are even some type of 'super-capacitors' (GoldCaps is a common name) that can do this. When the SRAM is used, ofcourse it will need an ordinary power supply, instead of the backup. Memory IC's that really don't need ANY power supply to keep their contents, are ROM (contents put in there when manufactured), and EPROM. The main disadvantage an EPROM has when compared with battery-backupped SRAM, is that it can only be re-written a limited number of times, usually in the order of a couple of thousand times. This also mostly needs to happen outside the system it's used in. For SRAM, such a limit doesn't exist (well, until it goes broke). Big advantage for EPROM's on the other hand, is that they don't need such a power supply backup. For 'normal' EPROMs erasing is done by ultra-violet light, and the glass window in the EPROM shows it to be such a type. Flash memory is in essence similar to EPROM, but can be erased electrically, so these don't need, and thus don't have such a glass window. FInally, there's even PROM, this is essentially EPROM as well, but to keep it cheap, this is put into ordinary glass-less IC packages. That makes them cheaper to produce, but because they miss that glass window, they can't be erased with ultra-violet light, and so they can only be programmed once. If you want to know more about these, there's plenty of reading material on this available from the manufacturers of such IC's, like Intel, AMD, Texas Instruments, .(some 50 or 100 more to choose from) 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: copy ethics
ed with a 'key' file. I think TED for instance, is one of the best examples: no extra troubles for the users, every copy 'branded' with the name of the rightfull owner, and even if this would be ignored, I'm sure that the mentioning of the good case it was related to (Multiple Scleroses) will have made several people buy one, when they wouldn't have otherwise. This cause it was related to, surely benefited from that somehow. And yes, if you want to, you can keep using it on your PC (works fine on emulators I tried). Isn't that the way to go? 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: make that ANY clockspeed
Manuel Bilderbeek <[EMAIL PROTECTED]> wrote: > > I know that the clockspeed of the MSX-computer can be increased with a > > 'special' upgrade. In the past such 'upgrades', increasing to +/- 7 MHz, > > existed and could be bought. > > > > Does anyone know of the existence of such upgrades or knows where I can find > > such schematics? Or any information? > Look in old MSX magazines (like the MSX Club Magazine, which later merged with MCM), for example numbers 31 (sept./okt.1990, original publication of 7 MHz. design), and 34 (mrt./apr. 1991, imrovements & corrections). Forget about 6 MHz. though, this design was always 'buggy' from the start, I doubt it's ever been perfected > Alwin Henseler (the hardware man of former MSX CLub Enschede) promised to me > that he would publish a complete 7 MHz schematic on the Computer Club > Enschede's homepage. Look for it on > > http://www.twente.nl/~cce/index.htm > No, this is not a 7 MHz. schematic, but for ANY speed (your MSX can cope with). Actually it switches between two 'random' speeds (wide range possible), so you can as well use it to have your MSX run on a speed switching between 2 and 5, or 6.1 and 3.2 MHz. (whatever, don't ask me what your MSX will do in such a case). BTW. it's probably suited for other Z80-based systems as well, but don't bother me about how to speed up a ZX-Spectrum or so with it, you figure that one out... And no, it will not be on the HOMEPAGE of the computerclub Enschede, because we don't do all that much with MSX anymore (apart from the occasional emulator). I do feel a stronger getting need to create some MSX pages of my own (probably hardware-stuff mainly), but either it will be as a 'sub-site', or it will be on some personal webpages of mine, but not on the homepage of our computerclub. Do look out for it though! Alwin Henseler ([EMAIL PROTECTED]) P.S. I believe our site is still the only place where you can get a fl. 2,50 discount on the entrance fee for the upcoming Zandvoort fair! (check out, what you have to do for that) 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 Super Turbo
Hi you MSX lovers! This might interest all you speed-freaks (and I mean hardware-wise, for those who still use a standard 3,6 MHz. MSX): In the past I have developed my own turbo-circuit, I call it MSX Super Turbo, and this has been entirely through the process of refining, testing, updating, redesigning, having it built into a bunch of MSX machines, and let these work for a couple of months (or years), to find out any problems with it. In other words: we're talking about a 'solid' piece of circuitry here. What is it: it is a solution to the general problem of switching the clockspeed of a Z80 CPU between 2 'random' frequencies, that don't have any relation to each other (unlike for instance the well known 7 MHz. design). Because of timing requirements of the Z80 CPU, this is not all that easy, but I found a good way to do it. Several people have been asking me if I still build these things into MSX machines, and I'm rather reluctant to do it, having not TOO much interest anymore in MSX, were further development is concerned. Therefore I've been wanting to put my stuff on the web, so that anyone interested can build it for him/herself, or find someone else to do it for them (and don't need to bother me about it anymore). Only: they would ofcourse need stuff like the schematics, a practical building description, and some info to go with it. That's coming up now! In contrast to other things I (have) put on the web, I will use a new approach here: I will put everything on this on the web, as soon as I have it, in other words: if a picture doesn't look right yet, I will put it up there anyway, and if I have a better one next day, there will be a better one up there the next day. That's where you come in: ofcourse you will find a mess on this page, and I want you to tell me what should be done! The end result will be that I have my design available on the web, you have an excellent piece of MSX hardware 'for grabs', and you will know that the form it's available in, is tailored to YOUR desires! So, I have 'allocated' the following address for it (in the page itself is a link to it, so that you can use a previously saved version to jump to the web-address where it came from): http://huizen.dds.nl/~alwinh/msx/supturbo If you want to, please add this to MSX hardware-related pages, so that other people 'just browsing' will come along, and be able to comment on it. Let's see what happens! Alwin Henseler e-mail: [EMAIL PROTECTED] MSX lives! (one way or the other, but there's no doubt about 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/)
VG8235 for sale...
Hi folks! I place this 'add' here for a 3rd person, I don't know if this is the 'right' place to put such an add, but I think it's a SUITABLE place for it: For sale is: (it's in the Netherlands, if you're outside the Netherlands, forget it, replies are probably preferred in Dutch) Philips MSX-2-computer VG 8235 (it's got a SS drive; original type?) Philips MSX Matrix printer NMS 1421 Philips MSX Monitor VS0040 All included instruction booklets and software (Home Office, Designer) All equipment working fine. price: fl.50,- for the lot Also available: a Sony MSX color monitor (exact data nor condition mentioned) Replies shoud go to: e-mail: [EMAIL PROTECTED] phone: 053-4329887 (in Enschede, the Netherlands) 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: NO ACTION REPLAY FOR THE MSX
> DEAR SIR > > > >I AM TRYING TO FIND THIS CARTIDGE THAT HELPS ME IN FREEZING ANY PROGRAM IN THE >MSX MEMORY AND TRANSFER IT TO TAPE OR DISK ,SO PLEASE CAN U HELP IN THIS REQUEST ? > > > > >TRULY YOURS > > >NABIL WAFAI > > Stop looking, there is no such thing! Such a cartridge usually works by some special electronics inside it taking control of the computer for a short while, and transferring CPU status, memory contents etc. to the cartridge, so that it can be restored later on, or saved to disk, whatever. This will not work on any MSX, because: -MSX machines are just too complex for this (in this respect it is the same as for PC's, ever seen such a cartridge for a PC? Just can't be done) -The MSX system doesn't support Direct Memory Access (DMA), required to read out system memory from 'outside' -For these other 'simple' systems, like ZX Spectrum, C64 etc., something in the order of 64 K storage in such a cartridge will do, in the MSX you might need 512 K, 1, 2, 4 MB., or even more So: forget it. Only way to accomplish something similar, is to run MSX software on an emulator, that supports saving/restoring the emulated MSX's status, but this is another matter Greetings, Alwin Henseler ([EMAIL PROTECTED]) check out my MSX Super Turbo design (webpage almost finished), it OBSOLETES things like 6 & 7 MHz http://huizen.dds.nl/~alwinh/msx/supturbo 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/)
6 or 7 MHz. info 'online'?
Hi you MSX-freaks, I'm about to finish the work on my MSX Super Turbo page http://huizen.dds.nl/~alwinh/msx/supturbo and, just as a matter of 'reference', I'm curious: does any of you know of a description of either CUC's 6 MHz. circuit (let's just forget about it), or the well known MSX 7 MHz. circuit, ON THE WEB? (or at least, in an electronic form, like on a disk-magazine or something like that). And I mean, a description OF these things (how they're built, circuit layout, schematics, how to build these into MSX's, that sort of stuff, NOT what they would cost, or where they could be bought, once upon a time) Then, about these things: I have in my possesion a number of MSX magazines. In numbers 31, and 34 of MSX Club Magazine, there is the publication of the 7 MHz. circuit (it's a long time ago). Does anyone now of any other publications (this, in any form) containing more TECHNICAL specifics about this 7 MHz. circuit, like improvements, or a new circuit layout, in a magazine I don't have? About this 6 MHz. circuit, I wonder: has it EVER been PUBLISHED? And what became of it anyway? As far as I know, there's always been a copyright issue involved in this 6 MHz. circuit, maybe therefore I've never seen a publication of it, and when the 7 MHz. circuit 'hit the market', I suspect it was more or less abandoned. Maybe they buried the papers of it somewhere, never to be found again And last (but not least?): does anyone know of other circuits like this, apart from Z180 or Z380 projects heard of earlier, so let's say, "7 MHz. replacements"? Greetings, Alwin Henseler ([EMAIL PROTECTED]) website: www.twente.nl/~cce/index.htm Hit this site for your Zandvoort fair discount ticket..!! (Dutch & English versions available, both in HTML and text format) 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: clockchip battery
[EMAIL PROTECTED]wrote: > But apropos clockchip: my 8250 is having problems keeping up to date. > I guess the battery will not live till the end of the year, let alone > till the millenium-change :-( > I know that the battery is soldered to the mainboard. Could it be possible > to take it out and replace it with e.g. a battery holder and a normal > AA (penlite) battery? If not, what alternatives do I have? There's a difference here you will have to watch: that between rechargable batteries, and that of 'discharge-only' types. The one normally in there is a rechargeable one (in a broke 8280 I've got here, it's a 3.6 V/45 mAh type, it should be ABOUT 3 V, so 2 OR 3 penlites would replace it). This type needs to be recharged, and is done so, when the computer is on (duuhhh...). It might be, that your clockchip battery just ran empty, when you didn't use the machine for a while, or use it very short, now and then. I would recommend just leaving your MSX on for a day or so, maybe your problem disappears after that. If not, any replacement would depend on whether you think of using this machine regularly in the future, or not. If yes, replace it by rechargeable batteries (try 2 mini-penlites, there's gotta be space for that, just 1:1 replacement will do, I guess). If not to be used regularly, you'd probably better replace it by some long-lasting battery, take 2 alkaline mini-penlights, or such a 3 V flat round lithium-type. But: if you use a non-rechargable battery, you have to make sure it doesn't get recharged (!!!), these things can't stand that. I've never seen it, but they might go broke in some spectacular way, and leave your home smelling bad for a couple of days=8-(( How not to recharge these: remove in the 8250 either resistor R162 (220 ohm), or diode D130 (any one of these, or both, doesn't matter, I suggest you take the resistor). Both are next to the battery, on the + side, and you can put it back in when you decide to change the battery for a rechargeable one later on Greetings, Alwin Henseler ([EMAIL PROTECTED]) website: www.twente.nl/~cce/index.htm 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: TEAC drive
Hi you all... Maarten ter Huurne <[EMAIL PROTECTED]> wrote: > >From an old PC, I got the following drive: > TEAC FD-235HF > Sounds familiar somehow, I think it's a 720 K type... > It has a huge jumper area (5 jumpers and 28 positions). So finding out > what-is-what by trail-and-error is a not something I look forward to. > > My questions: > - Does anyone have a description of which jumper position means what? > - Does anyone have this type of drive working in an MSX? If so, please tell > me your jumper settings, your MSX type and whether it's connected as > A-drive or as B-drive. There's only 2 things that should be needed, where jumper settings are concerned: a) Drive select, usually marked with something like "DS0 / DS1 / DS 2 / D3" (number of Dx can differ), where "DS0" stands for A:, and "DS1" stands for B: (ever seen a floppy drive C: on MSX?). If it should be the A: drive, set it to DS0, if it's a second drive, set it to "DS1" (=factory default) b) Some MSX-machines require a 'ready' signal on pin 34 of the floppy-connector. To avoid unexpected problems resulting from this, look for a jumper named something like "DC / RDY" (sets DiskChange, or ReaDY signal on pin 34). If you spot something like that, set it to "RDY". Other jumpers can usually be left alone. If things are not working, you can try setting these differently. One at a time, no setting should be able to cause permanent damage, so try anything. If no effect is seen, set it back the way it was, and try another. If that doesn't help after setting all jumpers present back and forth, consider it a lousy diskdrive I found a Teac FD-235F (sounds a lot like it) in a box with trash at my place, it's got jumpers named "FG" (forget this one), "D0" (A:), "D1" (B:), "DC" (DiskChange, should be empty), "RY" (ReadY, should be present), "IR" (?, leave it alone), and "MS" (?, rather not mess with it either). "D2" (C:) & "D3" (D:) a bit further on, but not as jumpers, just soldering pads. Maybe this helps? Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://www.twente.nl/~cce/index.htm http://huizen.dds.nl/~alwinh/msx/supturbo 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: TEAC drive
Maarten ter Huurne <[EMAIL PROTECTED]> wrote: > > >From an old PC, I got the following drive: > > > TEAC FD-235HF > > > > Sounds familiar somehow, I think it's a 720 K type... > > No, it's a 1.44MB (HD) drive. > Aah, so: Teac FD-235F = 720 K Teac FD-235HF = 1.44 MB (at least we know that then) > I am connecting it to an FS-A1GT (turbo R), which needs both Ready and > DiskChange. > Ai, that might be difficult indeed... > But I still have some troubles with this drive. Symptom: drive will > not spin and the LED only flashes a few times. > I think the problem is somewhere in the order of the Ready and > MotorOn signals. It seems the turbo R won't give MotorOn until it has > received Ready and the drive won't give Ready until it has received > MotorOn. Is this possible? > I came to this idea because I noticed that short-circuiting the > MotorOn signal made the drive work, as did short-circuiting the Ready > signal. As far as I know, MotorOn instructs the drive to start spinning, some 'dumb' drives do this right away, other drives with a bit of 'brains' only react on it, when a disk is detected in the drive, and keep still when not. When de-activated, most drives keep the disk running a few seconds after that, regardless of any software-controlled delays. If you permanently ground it, that means that a disk you put in the drive will start spinning right away, and will keep on doing so 'infinitely' as long as it's in the drive. If it solves your problem, you might do so, but it doesn't seem like a good idea to me. The Ready-signal indicates whether the disk has reached 'normal operating spinning-speed' (5 times round / second), so normally, the drive should only be able to activate this, when the disk already is (MotorOn activated previously). I guess you kind of got this far. I own a MSX2+ myself, with the same floppy-controller (TC8566) as in the Turbo-R, and have hooked up quite a number of drives to it in past years. My impression is, that this FDC is a bit more 'choosy' when it comes to whether a drive 'will do' or not, I suspect it's got to do with signal timings (as you mentioned). As a result, some older drives can't get to work with it, most newer (new) drives are no problem. But, IF they work, it usually works far more reliable, far less 'strange disk errors'. It might be that you're just out of luck on this one, and that there's no way to get your drive to work with this Turbo-R floppy-controller. But then I remembered something else that might do the trick. I don't know if this an issue here, but I will mention it. I've got a magazine artricle somewhere, I looked it up, and found this: some older HD drives determine DoubleDensity or HighDensity by looking at pin 2 of their connector. Practicly all newer drives do this by detecting the extra hole in HD disks, but some older drives need to be told by the FDC, how to go about. If this is so, pin 2 on your drive might need to be grounded (open = HD, grounded = DD). 'Officially' pin 2 is simply 'undefined', I'm not sure, but I think some drives use it to put a DiskChange signal on this pin, for instance. If all this still doesn't help, I suggest you forget about hooking this Teac FD-235HF up to a Turbo-R Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://www.twente.nl/~cce/index.htm http://huizen.dds.nl/~alwinh/msx/supturbo 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: Ramfile expansion?
> Jimmy Hoffa <[EMAIL PROTECTED]> wrote: > > I have something called a "Ramfile" made by a company named "Tecall". It has > 16 kb batterybackuped RAM, and my question is if its possible to expand ram on > it? Its very useful, since it allows the usage of files similar to > autoexec.bas and so. The two memory circuits, are of type 6464. > > "JAPAN 8707 > HM6264LP-15 > UO522YYO" > I read: 6264 -> 64 Kbit Static RAM (8K x 8 bit = 8 KByte), 28-pin the "-15" reads as: access time: 150 nanoseconds max. "LP" probably stands for Low Power, which can be read something like: specially selected/produced devices with extremely low power consumption (under certain conditions), usefull for battery-backup for instance (or laptops, or ) I'd gamble the "HM" before it means these parts were produced by Hitachi, doesn't matter much who produced these anyway. These can be easily replaced by 'bigger' types: 62256: 32 K x 8 bit (would give 64 KB. on your thing), 621024: 128K x 8 bit (would give 256 K on your thing). There are bigger ones, and under different type numbers, but they are available. Mail me if you need pinouts or something. > The ROM is of kind "HN27128AG-25". > This reads as: 128 Kbit EPROM (16 K x 8 bit, so 16 KByte), access time 250 nanoseconds max. Probably contains the software controlling this thing. > Please help me with this. :) > > // Jimmy Hoffa > > > - -- -- - --- -- -- -- --- --- -- > [EMAIL PROTECTED] -- - http://c5.hakker.com/ > > For PGP key and additional information, finger [EMAIL PROTECTED] > -- -- --- --- -- -- --- -- -- - --- -- - - - - > There are about a 1000 ways to put such a thing together, or expand it, it would see 3 basic steps: a) Put in larger memory (piece of cake here, altough SRAM's are relatively expensive, up to a couple of hundred KB's this should be no problem). Usually these newer/larger memory IC's have a power consumption comparable, or less, than older parts, PER IC. So a 128 KByte SRAM would use about as much, or less current as a 32 Kbyte one. No need to make changes to the battery backing these up... b) Expand the controlling mechanism, so that these can be used c) Modify the software, so that it uses this new controlling mechanism & extra memory I find this an interesting piece of equipment (I made a design for something like it sometime, just never took te time to build it...), but please answer these questions: a) Can you read out this 16 KByte ROM, and maybe put it on the web somewhere? b) Is it possible for you to make some kind of a circuit diagram of the hardware in this cartridge (maybe send me a copy, on paper would be okay) ? If you need any extra info about this, like IC pinouts, or MSX cartrdige-slot connections, please mail me. Alwin Henseler ([EMAIL PROTECTED]) http://www.twente.nl/~cce/index.htm http://huizen.dds.nl/~alwinh/msx/supturbo 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/)
Zandvoort fair 1998: final warning...
Juuussst in case you didn't know already: Thursday.Friday.Saturday, and then there is another MSX-fair in Zandvoort, the Netherlands (september 19). The place: sporthal (in English = ???) Pellikaan (double L, no writing error), Moolenstraat 5 in Zandvoort. It's very close to the train station, if you get there, you can just follow the masses (?) flowing into the building:-)) Time: 10.00-17.00 hours. Entrance fee: fl. 7,50 dutch guilders Get a fl. 2,50 discount with a discount ticket, available at: http://www.twente.nl/~cce/index.htm (computerclub Enschede) Dutch & English versions available, both in text & HTML format. Greetings, Alwin Henseler, 'webmaster' for the (small !) computer users group Enschede e-mail: [EMAIL PROTECTED] One more thing: don't forget your umbrella :-< 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: VDP 9938
Hi you all! > Oberleithner Wolfgang <[EMAIL PROTECTED]> wrote: > > Does anybody know how the Video-Ram-contents is changed > depending on the settings of the moderegisters? > > mode registers: > M5/1 - Screen select > 0 Screen 1 > 1 Screen 0 (WIDTH 40) > 00010 Screen 3 > 00100 Screen 2 > 01000 Screen 4 > 01001 Screen 0 (WIDTH 80) > 01100 Screen 5 > 1 Screen 6 > 10100 Screen 7 > 11100 Screen 8 > As far as I know, there is NO DIRECT influence from these VDP mode registers on the VRAM, they only control how the VDP handles it (display, command execution). So changing these does not do anything with the VRAM, set these bits back, and the VRAM is still the same. 2 remarks here: -Ofcourse it might have an influence on an already running VDP-command. Sounds a like a good way to screw up VRAM contents: start some VDP block command, and then toggle some of those mode bits, while it's running. Might be a nice way to produce all kinds of beautifull screen patterns -For most screens, there is a relationship between the exact VRAM address, and the VRAM page/pixel-coordinates that is about what you would expect. In some screen modes (I think Graphic 5 & 6 modes, that is, SCREEN 6 & 7), this relationship is different, so the contents of for instance 2 SCREEN 5-pages is not visible in one SCREEN 7-page, but 're-arranged' somehow (does anyone know how exactly?). In SCREEN 8, this is 'back to normal'. > > Is there any relation between the _SINGLE_ bits and the vdp-behaviour? > > f.e. bit 1 set:maximum 256 colors (unset: 16 colors) > bit 2 set:display 128 bytes per line (unset: 256 bytes) > ... Hey, I guess there must be, because it's all implemented in hardware somehow... V9938 databook doesn't tell, so this is 'undefined'. Only way to find out is to investigate a real V9938, and no guarantees it will work the same in for instance a V9958 (or other compatible?) Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msx http://www.twente.nl/~cce 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: MSX1 & slot-expansion
Time to set some things straight here: (and would you guys/dolls please change the subject of your messages when this changes?) > > > >MSX1 and slotexpander... Some how I don't think so... > > Why not? After all, the slot expander is switched using memory mapped I/O > at $. MSX1 can do that as well. > Note that the MSX1 BIOS doesn't support slot expansion, though. Which means > that only cartridges in the first subslot will be recognized by the BIOS. BULLSHIT !!! MSX-1 and expanded slots are perfectly 100 % compatible, AND supported by BIOS-routines: -MSX-1 Technical Databook even shows a sample circuit diagram for expanded slot select control -MSX-1 BIOS routines dealing with slotswitching have the same 'specifications' as MSX-2 counterparts, and INCLUDE sub-slot switching/reading/writing/calling -MSX-1 and MSX-2 slotswitching-routines ARE essentially the same, I think I figured out some minor differences once, but that's just details (performance-related or such), sub-slot use is absolutely FULLY supported by MSX-1 BIOS routines -I had a Philips NMS 8020/40 once (with expanded slot 3, like the Philips MSX-2 models). Apart from having to add this famous POKE -1 to several game loaders, which wouldn't be necessary for most MSX-1's, I had absolutely NOOO problems with it, running programs on this MSX-1 was 'business as usual'. I even had a memory mapper in there once, after a first initialisation 'by hand' (MSX-1 BIOS routines don't do THIS, but otherwise MSX-1 and memory mappers are no problem either), several 'MSX-2 only' MegaROM cracks (Nemesis and such, originally MSX-1 as you will know) ran fine, even in a sub-slot (and no, this was not the first sub-slot only, or the last, but slot 3-2, as in the Philips MSX-2 models). Besides: This RAM-file cartridge that started all this, must be something like a 'stand-alone disk-driver', that more a less works just like a separate disk-interface, so I'm sure this guy CAN simply boot to BASIC, and read out the ROM by software. Apart from that: If you DO want to insert a cartridge in a running MSX, there's a safer way to do it: hook up a switch between +5 V and the slot-select signal of the slot you want to disable, then, when booting the machine, switch it on shortly, just after the MSX-logo appeared (when slots are searched), which short-circuits the particular slot-select signal with +5 V, making it 'high' (inactive), and thus disabling this slot, for as long as you keep the switch on. Absolutely worst thing that can happen if you do it this way, is destructing a slot-select signal output of some custom IC (S-3527 MSX-engine for instance), which would make this particular cartridge-slot useless. In practice, you would probably have to short-circuit it for a long time (minutes, hours) to do so, and in fact I doubt it would ever happen (if only 1 output is short-circuited, for most IC's this means no more than handling the excessive heat-production caused by the short-circuit current of this 1 output, making it 'peanuts' for many IC's). All clear now? Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://www.twente.nl/~cce/index.htm(computerclub Enschede) http://huizen.dds.nl/~alwinh/msx (yep, some MSX-pages of my own have appeared, I called it 'the MSX Tech Doc page', a bit empty now, just my MSX Super Turbo circuit, and a home-built cartridge-loader (check it out if you could use one!), but more will come...in time) 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: VDP 9938
> By the way, there are some bits in a VDP register controlling "VRAM
> config". Have you tried them? Any effect?
>
I tried these once, I can't remember having noticed ANY effect. I can
imagine this: some older DRAM-IC's (like ...K x 1 bit types) have
separate data inputs and outputs, and/or require different timings
for the control signals. My guess is, that these VDP-bits indicate to
the V9938, what timings/control methods to use.
In practice, it's probably so, that the usually used 64 K x 4 bit
DRAM's also accomodate timings as used for older DRAM's, making the
exact method used a don't care (and therefore don't show any effect
on common MSX machines).
Then somebody mentioned that he couldn't find any 'new' screen modes,
well I know of one, but I guess this must be more or less known
already, it's MSX-1 specific:
In SCREEN 1, colors for the characters are set for groups of 8
characters. In SCREEN 2 (graphic mode), this is for each 'character'
separate (background/foreground-color set per horizontal line of 8
pixels, in both cases), and the screen consists of 3 groups of 256
'characters'. I know of an 'in-between' of this, giving a textmode,
with 256-element character-set, where for each character separately,
a backgrond/foreground-color can be set per line of 8 pixels.
The BASIC listing below uses this effect, and you could study it, to
see how it's done (not that I care, just maybe an interesting fact):
10 DEFINT A-Z
20 ' DE TRUC: (VARIATIE OP SCREEN 1)
30 BASE(5)=6144: BASE(6)=8192: BASE(7)=0: BASE(8)=6912:
BASE(9)=4096
40 SCREEN 1: COLOR 10,1,1: CLS
50 VDP(0)=VDP(0) OR 2: VDP(3)=159: VDP(4)=0
60 A=&HF3E9:K=16*PEEK(A)+PEEK(A+1)
70 FOR A=BASE(6) TO BASE(6)+2047: VPOKE A,K: NEXT
80 ' DRUK KARAKTERSET AF
90 FOR K=32 TO 255: PRINT CHR$(K);: NEXT K
100 ' STEL KLEURKODES IN VOOR 'SCHADUWLETTERS'
110 FOR K=0 TO 255
120 A=BASE(6)+8*K
130 VPOKE A+3,144: VPOKE A+4,144
140 VPOKE A+2,128: VPOKE A+5,128
150 VPOKE A+1,96: VPOKE A+6,96
160 VPOKE A,208: VPOKE A+7,208
170 NEXT K
180 ' ZET NOG EVEN EEN SPRITE OP HET SCHERM
190 SCREEN ,2: S$="": RESTORE 220
200 FOR N=0 TO 31: READ B$: S$=S$+CHR$(VAL("&H"+B$)): NEXT N
210 SPRITE$(0)=S$: PUT SPRITE 0,(220,160),10,0
220 END
230 DATA
3,F,1F,3F,3F,7F,7F,FF,FF,FF,7F,7F,3F,3F,1F,7,C0,F0,F8,38,7E,F8,E0,80,
8 0,E0,F8,FC,F8,F0,E0,80
Ofcourse, on the V9938 and higher you can combine this with color
palette functions. Maybe this works as well with SCREEN 4 (SCREEN 2,
with improved sprite-functions), but I haven't tried that (who uses
SCREEN 2 or 4 anyway).
What WOULD be interesting to know:
If there is a number of bits controlling the screen modes, and there
are less screen modes, than possible combinations of these bits, WHAT
screen-modes DO you get, when setting one of these undefined
combinations that are possible?
If anyone ever figures this out, I'm sure it will interest some of
us, so dump it on this mailing-list, should you find any answers to
this
Greetings,
Alwin Henseler ([EMAIL PROTECTED])
http://www.twente.nl/~cce/index.htm (computerclub Enschede)
http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page)
Aaahhh, I think the weather clears up after all, and you can leave
your umbrella's at home when going to Zandvoort...:->
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 MSX HAS lightpen built-in
Hi guys (& dolls?), NYYRIKKI <[EMAIL PROTECTED]> wrote: > This VDP is not so stuppid that it looks. I'm waiting instructions to > build my own Light pen for it. I have heard, that it can use Light pen > even in screen 0 and 1 !!! Why any MSX has no ready light pen connector ? > Light pen is so sheap, and easy to make ! (it has only one > light-transistor, one resistor, button and ofcource cable and connectors) Oops! Some MSX HAVE a light-pen connection buit in, using the VDP! I investigated a Korean-built MSX-2 once, it looked a bit like the Philips 8250/55, but with different parts, and highly incompatible with many MSX software. This thing had a light-pen connector on the front of the machine, and curious as I was, I made a circuit diagram of the way it was hooked up to the VDP. Want it? Mail me! (contents of the ROM in this machine, and other hardware details available as well). I do remember that the construction of this light-pen connection was really simple Oh yeah, I'm talking about a Daewoo CPC-400S here (not such a funny looking 'gameconsole', but a 'regular' built home computer). 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: 8235/00 and 8235/20
> >>Ah, the famous /20-series... Can anybody tell me the difference between > >the > >>VG8235 and the VG8235/20??? > A service manual I got, indicates there are even /02 and /19 types, apart from /00 and /20. I can't remember ever having seen a /02 or /19 type. I'm not quite sure, but I think there is a 8235/40 as well. >From the outside, there's no difference to be seen, other than the type number on the bottom plate. The difference is on the inside. >From a hardware-builders point of view, there's only 2 kinds of Philips 8235's: 'older models' (I think that would be /00 up to /19 types), and 'new' models (that would be /20 or higher). These older models have a relatively big motherboard, with a relatively large number of parts on them. The circuit is put together so clumsy in some ways, Philips ought to be ashamed to have attached their name to it once (for instance, the VERY first memory mapper circuits I built myself once, as an experiment, were put together better already than the circuits used inside these machines). In fact, these machines are built so lousy in just about every way (never did like the 8235 anyway), that if you have one, there's no shame in piling these up in some corner, to maybe use them for spare parts some time. I know, a REALLY sad, sad way to go for any computer ;-(( But hey, if you could use a part from such an old 8235 to bring another MSX back to life, that might be a good deal indeed... The newer 8235 models have a completely different designed motherboard: much more compact, all ROM's packed together in one, etc. In fact, these 8235's look (on the inside) just like the Philips NMS 8245 (that one with DS drive, and non-adjustable keyboard). The print-layout IS different, but most (maybe even all?) parts are numbered/named the same as in the 8245. In fact, when you have such a newer model 8235 in front of you, you can just take the service manual for the NMS 8245, and use this as if it were of this 8235, just about everything checks out (you might have to look somewhere else on the circuit board for a certain part though)! Only power supply circuits, and mechanical construction differs between these newer 8235's, and the 8245 (and the SS vs. DS drive, ofcourse). I guess that would explain the disappearing of such a dumb memory bug too, simply a more modern circuit & printed circuit board layout in the 8235/20. BTW: I think this memory bug on older 8235's has some easy 'fix', I could try and look it up, if anyone wants it. I'm not sure what this memory bug was about, I did reproduce it myself once or twice, it more or less simply came down to: 'unreliable memory mapper switching'. Greetings, Alwin Henseler ([EMAIL PROTECTED]) http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page) http://www.twente.nl/~cce/index.htm(computerclub Enschede) Aaahhh, for once, the weather really was great, today in Zandvoort! 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: Interrupts
Hi,
> Rainier Maas schreef:
>
>> Hi!
>>
>> I have a little question:
>>
>> - Interrupt occurs
>> -> (DI)
>> -> Interrupt Routine (-> new interrupt occurs)
>> -> EI
>> -> ret
>>
>> What will happen if a NEW interrupt occurs when the MSX is
>> processing obove mentioned "routine-part"?
>>
>> - After switching the interrupts on, will the MSX remember the
>> interrupt and calls again the interrupt-routine?
>>
>> OR:
>>
>> - Is the additional interrupt lost forever?
The interrupts (both maskable & non-maskable) are not 'remembered' by
the Z80, they are only 'sampled' at certain times. If the interrupts
are enabled at that time, the interrupt is 'taken', if they are
disabled at that time, this particular interrupt is lost.
When a (maskable) interrupt is taken, an automatic "DI" is done, so
that (maskable) interrupts are disabled right after that, followed by
a restart-instruction, of which the address depends on the interrupt
mode. With the normal IM 1 used in MSX, this is a "RST 38h" ("CALL
38h"). A databook I have, says that during the acceptance of this
interrupt, 2 extra wait states are added, to give the hardware extra
time to place an interupt vector on the data bus in IM 2, but these
extra wait states are also added for the other interrupt modes.
You SHOULD end a routine for processing maskable interrupts with RETI
(RETurn from Interrupt).
BTW: RETI <-> RET:
As far as I know, RETI and RET work exactly the same in all respects,
and are different only in the exact instruction bytes, and the number
of T cycles they consume. My guess is, that RETI simply serves to
INDICATE that it ends an interrupt-routine, rather than a normal
subroutine. For the rest, it's my belief that these 2 instructions
can fully replace each other (so that you can use a RET wherever a
RETI is used, and vice versa). There IS a difference between RETN
(with NON-maskable interrupts) on the one hand, and RET/RETI on the
other hand, but did anyone ever find a difference between RET and
RETI (other than instruction bytes and T cycles)?
When you want interrupts to keep occuring, than you have to re-enable
interrupts ("EI") SOMEWHERE before the end of the interrupt-routine.
I think in the MSX this is done somewhere after it has been
determined that the interrupt actually came from the VDP (as it
normally is), so that either the VDP can give a next interrupt after
it was determined that this one came from it, or in the rest of the
interrupt routine, interrupts remain disabled until some other source
of the interrupt is determined.
Of course, when calling BIOS routines, or other subroutines in such
an interrupt-processing routine, you have to carefully watch whether
it's okay if interrupts are re-enabled at that time, or avoid using
subroutines that re-enable interrupts.
Such an interrupt-routine might finally end with:
EI
RETI
When the EI instruction is executed, interrupts remain disabled (!)
for 1 more INSTRUCTION, in other words: after the EI, an interrupt at
that time would still not be accepted. First one more instruction is
executed, and THEN another interrupt might be accepted.
In the above example, an interrupt between the EI and RETI would
still be ignored, only after the RETI is executed, a new interrupt
could occur.
This one-instruction delay after EI is provided, so that if you end
an interrupt-routine with a RET(I) directly after the EI-instruction,
the RET's get executed first (getting a return-address from the
stack), so that the stack won't get bigger all the time if interrupts
follow directly after each other.
For the rest, it's perfectly possible to have an interrupt-processing
routine being interrupted, and this next routine being interrupted
itself, etc. etc.
This is only limited by practical issues, like stack space, time
required to process interrupts, and the frequency at which they
occur. If you want things to keep working, you have to provide enough
stack space, make sure that interrupts occur only at such a rate that
the CPU can process them, and make sure an interrupt-processing
routine is built properly.
Well, it's time to interrupt this thing now;-)
Greetings,
Alwin Henseler ([EMAIL PROTECTED])
http://www.twente.nl/~cce/index.htm(computerclub Enschede)
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/)
lightpens only directly hooked to V9938..
Hi all, I mentioned earlier a Korean MSX2 (Daewoo CPC-400S), with a lightpen-connection built in. Some of you got excited, and said: why not hook this to my MSX? Just a couple of wires to the VDP There's a couple of things I forgot to mention here: -I don't think you can do this with the MSX-1 VDP, at least not in the same way (apart from other ways of hooking up light-pens). -In the V9958 (MSX 2+), this function is deleted. 'uninteresting'? Anyway, from V9938 -> V9958: composite video output and mouse/lightpen interface deleted, the signal pins involved used for something different. So this hooking up of a lightpen directly to the VDP, only goes with a V9938 (MSX-2) Not that MSX-1 matters much in this repect... About using a V9990 for this: I wouldn't know... Need any software for it? Just debug any MSX-2 subROM, I think light-pen software is built in the same BIOS-routine(s) handling the mouse, and paddles, and graphic tablets, and lightpens (if any). Interesting thought: Maybe there already exists some software using such a lightpen (via these BIOS-routines), just nobody knows, because these lightpens are not around that much Greetings, Alwin Henseler([EMAIL PROTECTED]) http://www.twente.nl/~cce/index.htm(computerclub Enschede) 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: Return to interrupts
) The RET after that is simply shorter, and faster than a RETI The 'signal' function of a RETI mentioned earlier by someone, is simply not used in any MSX hardware, so ending the interrupt routine with a normal RET just makes it a tiny bit faster. The rest of interrupt-related stuff is just a matter of how peripherals, like the VDP, generate them, and how you can control these peripherals doing this. Damn, these VDP's are complicated enough, though I hope this helps things a bit further, Alwin Henseler([EMAIL PROTECTED]) http://www.twente.nl/~cce/index.htm (computerclub Enschede) 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: PAUSE key - no BlaBlaBla
tofire (also working with the space bar), but NOT doing anything with CPU clock speed. In fact, I don't think there are ANY MSX-machines that have hardware for controlling CPU clock speed built in. Not even the Turbo-R, this thing doesn't change clock speeds, but changes CPU's instead... I did figure out this about this MSX2+ hardware-controlled pause: a Z80 "DI" instruction seems to disable it (jippie! yes! chaka!). I'm not QUITE sure, check out this piece of code to make sure: DI loop: (some dummy loop, taking up, say, 1 minute of CPU time) (no use of ANY other piece of hardware in this loop! No VDP, No I/O-ports, no memory-mapped I/O use!) EI RET Make your MSX2+ (or Turbo-R in Z80 mode?) enter this loop, and after say, 5 seconds, press the pause key, wait, say 40-50 seconds, then press it again (get out your stopwatch). If this pause function worked anyway, you should still have to wait some 55 seconds after that for the machine to come out of this loop. If the DI did disable the pause function, the pressing of the pause key within the loop would be ignored, and you would come out of this loop right after the 'planned' amount of CPU time is up. There is one big problem with this: it seems that there are various low-level hardware-actions that immediately re-enable the pause function again: -any VDP access, EVEN if still in "DI" state (damn..) -Z80 "EI" instruction (regardless of interrupt routines used) I'm not quite sure about these things either, and maybe there are more, you'd have to check these out one by one, for anything you plan on using during a period with pause disabled. But you see, it might still be possible... (hope this helps) Alwin Henseler([EMAIL PROTECTED]) http://www.twente.nl/~cce/index.htm(computerclub Enschede) 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/)
