Re: 64K VRAM?
At 14:26 29/03/99 +0200, you wrote: >> At 13:19 24/03/99 +0100, you wrote: >> >MSX and DMA??? Seems quite impossible to me... >> >Isn't it? >> >> Nope dudez, I've heard a lot about these possibilities, of MSX and >> DMA... Of course, rebuilding the computer and peripherals. But I don't know >> hardware enough to talk about. > >I would expect the hardware to use the busreq-pin on the z80. But is that >one actually in the cartridge-slot? I think so. Ricardo Jurczyk Pinheiro - ICQ UIN:3635907 - [EMAIL PROTECTED]|_Sola Scriptura | http://i.am/rjp -M.Sc. Numerical Modelling (hope so!) |_ Sola Gratia | UFF - Niteroi - RJ - Brazil - [EMAIL PROTECTED]_| Sola Fide | MSX, ST, B5, X-F, Anime, Christian, Maths, CuD, Linux!_| Solo Cristi | Christian, Rock, Comics, Transformers, and hate M$! | Soli Deo Gloria | 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? / DMA
>I would expect the hardware to use the busreq-pin on the z80. But is that >one actually in the cartridge-slot? Unfortunatly, no, it isn't... :-( It might be possible to add it to the MSX slot's, there are some reserved pins. However, just adding a wire from the ^BUSRQ signal to one of these pins isn't enough... It is relatively simple to control the direction of the databus. By means of busdir. But all the one-direction address drivers have to be replaced by bi-directional ones. If someone really makes a new MSX, DMA would be one of the things I would like to see. Now I come to another thing, on the R800, there seem to be some DMA control lines. Anyone knows how to use these? There are also 6 (?) interrupt pins, how does this work? And on the S1990, there are pins for high density select/detection (I am at university now, so I don't have the turbo-R manual here) Anyone knows on what registers these signals are located? Greeting, Erik Maas MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
RE: 64K VRAM?
Sure you are right, DTA is the correct name. And the one we should use. The term DMA was often used in CP/M (and often DMA hardware support was available in S100 bus systems) and therefore it appears sometimes because MSXDOS inherited much from CP/M. -Original Message- From: Laurens Holst [mailto:[EMAIL PROTECTED]] Sent: maandag, maart 29, 1999 10:45 uur To: [EMAIL PROTECTED] Subject: Re: 64K VRAM? >Hardware DMA indeed not possible with the builtin chips in the MSX. >But the term DMA stems from long ago (CP/M for eaxmple) when with DMA was >meant the memory location/buffer where the transferred data to/from is >stored. That's not DMA, that's DTA... Disk Transfer Area. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
On Thu, 25 Mar 1999, Ricardo Jurczyk Pinheiro wrote: > At 13:19 24/03/99 +0100, you wrote: > >MSX and DMA??? Seems quite impossible to me... > >Isn't it? > > Nope dudez, I've heard a lot about these possibilities, of MSX and > DMA... Of course, rebuilding the computer and peripherals. But I don't know > hardware enough to talk about. I would expect the hardware to use the busreq-pin on the z80. But is that one actually in the cartridge-slot? Bye, shevek --- Visit the internet summercamp via http://polypc47.chem.rug.nl:5002 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?
>Hardware DMA indeed not possible with the builtin chips in the MSX. >But the term DMA stems from long ago (CP/M for eaxmple) when with DMA was >meant the memory location/buffer where the transferred data to/from is >stored. That's not DMA, that's DTA... Disk Transfer Area. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
At 13:19 24/03/99 +0100, you wrote: >>> The standard doesn't say anything about the method that the diskrom >should >>> use. So, it's just the case on many MSXs. The standard only says that the >>> interface should use memory addresses to transfer data between CPU and >>> FDC. >> >>Ok, but this means that using DMA in page 1 is against MSX standard, or >>not? > >MSX and DMA??? Seems quite impossible to me... It isn't... >Isn't it? Nope dudez, I've heard a lot about these possibilities, of MSX and DMA... Of course, rebuilding the computer and peripherals. But I don't know hardware enough to talk about. ByE! _ __ | __ \ (_| ICQ UIN: 3635907 | | M. Sc. In Numerical Modelling - UFF | |__) | _ __ _ _ __ __| | ___ Niteroi - RJ - BR +-+ | _ / | |/ __// _` | '__/ _` |/ _ \ | Sola Scriptura | | | \ \ | | (__| (_| | | | (_| | (_) | | Sola Gratia | |_| \_\|_|\___\\__,_|_| \__,_|\___/ Jurczyk Pinheiro |Sola Fide| http://pagina.de/rjp - [EMAIL PROTECTED] - [EMAIL PROTECTED] | Solo Christi | MSX freak, X-Phile, Trekker, Christian, Transformers, | Soli Deo Gloria | Anime (Yamato!), CuD, Gospel Rock, Comics, And hate M$! +-+ [Portuguese] Se vc e' usuario alternativo (Linux, MSX, Apple, Amiga, BSD, Sinclair, etc.) nao perca a 1a. ExpoSALT, dias 30 e 31/1/1999: http://www.wb.com.br/exposalt MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: page 1 diskloading (was: 64K VRAM?)
On Wed, 24 Mar 1999, shevek wrote: > On Wed, 24 Mar 1999, Jon De Schrijder wrote: > > > But this routine is only provided in MSX-DOS(2) environment; when in > > BASIC, a RET instruction is placed at #F36E. So: disktransfer in page1 in > > BASIC is probably not possible (or perhaps the F37D entry temporarily > > changes the #F36E hook; didn't test it); This is logical: BASIC ROM is > > normally selected in page 1. > > It is not that logical. I want to make a program that is started from > basic but switches ram to page 1. Than calling the diskrom on f37d with > dma in page 1 would be useful. Until now, I always avoided it, but I would > like to know if it would work on every MSX. If so, I could just as well > use it... I am sure that for Turbo-R and for port-based disk interfaces (Brazilian ones) you can do that. For other interfaces, I am not sure, but it should be possible. PS: I traced the Turbo-R's diskrom, and I can guarantee that! Greetings from Brazil! - Marco Antonio Simon Dal Pozhttp://www.lsi.usp.br/~mdalpoz [EMAIL PROTECTED] "Apple" (c) Copyright 1767, Sir Isaac Newton /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ 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: page 1 diskloading (was: 64K VRAM?)
Jon De Schrijder schreef: > On Tue, 23 Mar 1999, shevek wrote: > > > On Mon, 22 Mar 1999, Marco Antonio Simon dal Poz wrote: > > > > > On Mon, 22 Mar 1999, shevek wrote: > > > > > > > On Mon, 22 Mar 1999, Marco Antonio Simon dal Poz wrote: > > > > > > > > > For the most part of diskroms, DMA can be in page 1, because they have > > > > > access to FDC through addresses 7FF8h-7FFCh and also BFF8h-BFFCh, and they > > > > > transfer a small routine to F1BFh (or something like that) that allows a > > > > > disk transfer to happen in page 1. > > I don't think this is true. Yes it's true , on all philips , exept for some old VG8230 , also #BFF8 - #BFFC is used for accessing the fdd controller , a little code will be placed inside the sector buffer and used to transfer data to page 1. when you put the "fast" diskrom from a NMS8250 inside the VG8230 is will crash when you want to load msx-dos when you make a little modification and "mirror" 7FF8 etc to BFF8 it will work erik de boer -- > 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: page 1 diskloading (was: 64K VRAM?)
>> But this routine is only provided in MSX-DOS(2) environment; when in >> BASIC, a RET instruction is placed at #F36E. So: disktransfer in page1 in >> BASIC is probably not possible (or perhaps the F37D entry temporarily >> changes the #F36E hook; didn't test it); This is logical: BASIC ROM is >> normally selected in page 1. >It is not that logical. I want to make a program that is started from >basic but switches ram to page 1. Than calling the diskrom on f37d with >dma in page 1 would be useful. Until now, I always avoided it, but I would >like to know if it would work on every MSX. If so, I could just as well >use it... You can also start your program from DOS and switch BIOS on page 0: paging will be the same as when starting from BASIC and switching RAM on page 1, but you will have #F36E routine available. This should work. Just try. 8-) 15th MSX users meeting in Barcelona: May 1th, 1999 Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user New address!!http://konamiman.msx.tni.nl [EMAIL PROTECTED] ICQ#: 18281450 Metal Gear for MSX - (C) Konami 1987 (Nothing new under the sun...) 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/)
Betr.:: Re: 64K VRAM?
[Using disk I/O on page 1 ($4000-$7FFF)] > 2) It might be a problem when you are working under basic, using address > ªF37D to access the BDOS. Though, I'm not sure about that. I am. I tried to load some data somewhere in page 1 using an ML routine which was called from BASIC (DEFUSR=:A=USR(0)). Didn't work. I had to moved the DTA to page 2 and copy the data later to the destination address in page 1. (Until I discovered that I could as easily switch the memory mapper block I wanted to load the data in to page 2, load the data and then switch that block to page 1 :-)) Eric MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: page 1 diskloading (was: 64K VRAM?)
On Wed, 24 Mar 1999, Jon De Schrijder wrote: > But this routine is only provided in MSX-DOS(2) environment; when in > BASIC, a RET instruction is placed at #F36E. So: disktransfer in page1 in > BASIC is probably not possible (or perhaps the F37D entry temporarily > changes the #F36E hook; didn't test it); This is logical: BASIC ROM is > normally selected in page 1. It is not that logical. I want to make a program that is started from basic but switches ram to page 1. Than calling the diskrom on f37d with dma in page 1 would be useful. Until now, I always avoided it, but I would like to know if it would work on every MSX. If so, I could just as well use it... Bye, shevek --- Visit the internet summercamp via http://polypc47.chem.rug.nl:5002 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?
On Wed, 24 Mar 1999, Laurens Holst wrote: > MSX and DMA??? Seems quite impossible to me... > > Isn't it? Ehm... well, in the BDOS specs the term DMA-address is used for the start address of disk-actions (read-write). This is NOT the same as DMA on PC's... Bye, shevek --- Visit the internet summercamp via http://polypc47.chem.rug.nl:5002 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/)
page 1 diskloading (was: 64K VRAM?)
On Tue, 23 Mar 1999, shevek wrote: > On Mon, 22 Mar 1999, Marco Antonio Simon dal Poz wrote: > > > On Mon, 22 Mar 1999, shevek wrote: > > > > > On Mon, 22 Mar 1999, Marco Antonio Simon dal Poz wrote: > > > > > > > For the most part of diskroms, DMA can be in page 1, because they have > > > > access to FDC through addresses 7FF8h-7FFCh and also BFF8h-BFFCh, and they > > > > transfer a small routine to F1BFh (or something like that) that allows a > > > > disk transfer to happen in page 1. I don't think this is true. The DISKIO(#4010) can transfer data in page 1 through the following mechanism: when data is transferred in page 2 or 3, no slotswitching is needed. (bit 15 of the startaddress=1) When bit 15 of the startaddress=0: transfer to page 0 or 1: (also special slotswitching in page1 is needed when begin of transfer is in page 0 because transfer can be partially in page 1 too! example: from #100 to #6000) In that case: DISKIO gets sector bufferaddress in page3: pointer at address #F34D/E. This seems to be the standard address, both in DOS1 and DOS2. (It has to be, otherwise a floppydrive (DOS1) diskrom would not function anymore when running DOS2) This is a 512 bytes buffer, large enough to fit 1 sector. So when reading from device: data is transferred to the sectorbuffer. Then the registers are filled with values like for a normal LDIR (from sectorbuffer to final destination in memory) and a call is made to address #F36E (also standard for DOS1 and DOS2 kernels). Here a routine is provided to make the main ramslot active in page 1. Before making the ram active, the diskromslotcode is fetched by calling a 'where_am_i' routine in the diskrom (#402D I believe). When ram is selected in page1 an LDIR instruction is executed and the diskrom is reselected in page1. But this routine is only provided in MSX-DOS(2) environment; when in BASIC, a RET instruction is placed at #F36E. So: disktransfer in page1 in BASIC is probably not possible (or perhaps the F37D entry temporarily changes the #F36E hook; didn't test it); This is logical: BASIC ROM is normally selected in page 1. > > > > > > Is that MSX-standard or just the case on many MSXs? > > > > The standard doesn't say anything about the method that the diskrom should > > use. So, it's just the case on many MSXs. The standard only says that the > > interface should use memory addresses to transfer data between CPU and > > FDC. > > Ok, but this means that using DMA in page 1 is against MSX standard, or > not? don't know; I only noticed the following: *diskrom DISKIO supports it *F36E routines provided by DOS1/DOS2 *when you make a diskrom with no support for page1 disktransfer, all things work fine. I don't think DOS2 uses it; don't know about DOS1. Can you all confirm this information? jon 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?
On Wed, 24 Mar 1999, Hans Otten wrote: > Hardware DMA indeed not possible with the builtin chips in the MSX. > But the term DMA stems from long ago (CP/M for eaxmple) when with DMA was > meant the memory location/buffer where the transferred data to/from is > stored. > These days I use the term "DTA" (data transfer area) to mean that old DMA. This avoids lots of confusion, and can be easily changed in source codes using search-and-replace. Ricardo Bittencourt http://www.lsi.usp.br/~ricardo [EMAIL PROTECTED]"Save the trees: eat more woodpeckers" 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?
Hardware DMA indeed not possible with the builtin chips in the MSX. But the term DMA stems from long ago (CP/M for eaxmple) when with DMA was meant the memory location/buffer where the transferred data to/from is stored. -Original Message- From: Laurens Holst [mailto:[EMAIL PROTECTED]] Sent: woensdag, maart 24, 1999 13:20 uur To: [EMAIL PROTECTED] Subject: Re: 64K VRAM? >> > > For the most part of diskroms, DMA can be in page 1, because they have >> > > access to FDC through addresses 7FF8h-7FFCh and also BFF8h-BFFCh, and they >> > > transfer a small routine to F1BFh (or something like that) that allows a >> > > disk transfer to happen in page 1. >> > >> > Is that MSX-standard or just the case on many MSXs? >> >> The standard doesn't say anything about the method that the diskrom should >> use. So, it's just the case on many MSXs. The standard only says that the >> interface should use memory addresses to transfer data between CPU and >> FDC. > >Ok, but this means that using DMA in page 1 is against MSX standard, or >not? MSX and DMA??? Seems quite impossible to me... Isn't it? ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
>> > > For the most part of diskroms, DMA can be in page 1, because they have >> > > access to FDC through addresses 7FF8h-7FFCh and also BFF8h-BFFCh, and they >> > > transfer a small routine to F1BFh (or something like that) that allows a >> > > disk transfer to happen in page 1. >> > >> > Is that MSX-standard or just the case on many MSXs? >> >> The standard doesn't say anything about the method that the diskrom should >> use. So, it's just the case on many MSXs. The standard only says that the >> interface should use memory addresses to transfer data between CPU and >> FDC. > >Ok, but this means that using DMA in page 1 is against MSX standard, or >not? MSX and DMA??? Seems quite impossible to me... Isn't it? ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
>> For example, it's very useful for accessing the entire RAM using only the >> #8000-#BFFF segment. > >My MSX2 has 64kb of standard RAM and to access other pages I used to do >some LDIRs (i.e., I can handle that). 1. LDIRs are slow (OUT takes 11 ticks, LDIRing 16k takes, ummm, a LOT of ticks) 2. If you do what you suggest then the memory in page #8000 can't be used for it has to be used as a temp-page. So when 'emulating' 64k of mapped ram on 64k of non-mapped RAM you get (in the most optimistic case, so only when using one page for mapping) a VERY slow 48k RAM mapper. >> And DOS2 *needs* the memory to be mapped in order to manage the RAM properly. > >And does DOS2 work with 64kb of Memory Mapper? No. Minimal 128k. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
On Tue, 23 Mar 1999, Alex Wulms wrote: > ] Ok, but this means that using DMA in page 1 is against MSX standard, or > ] not? > I can say three things about accessing data in page 1: > > 1) It is no problem at all under MSX-DOS when you use address #0005 to access > the BDOS. > > 2) It might be a problem when you are working under basic, using address > #F37D to access the BDOS. Though, I'm not sure about that. Why it might be a problem? > 3) It is definitely a problem if you call phydio directly, either via 0x144 > in the BIOS or via 0x4010 in the diskrom. I ever used this routine calling 0144h or FFA7h and I have never had problems! What's the matter? Greetings from Brazil! - Marco Antonio Simon Dal Pozhttp://www.lsi.usp.br/~mdalpoz [EMAIL PROTECTED] "Apple" (c) Copyright 1767, Sir Isaac Newton /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ 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?
] > The standard doesn't say anything about the method that the diskrom should ] > use. So, it's just the case on many MSXs. The standard only says that the ] > interface should use memory addresses to transfer data between CPU and ] > FDC. ] ] Ok, but this means that using DMA in page 1 is against MSX standard, or ] not? I can say three things about accessing data in page 1: 1) It is no problem at all under MSX-DOS when you use address #0005 to access the BDOS. 2) It might be a problem when you are working under basic, using address #F37D to access the BDOS. Though, I'm not sure about that. 3) It is definitely a problem if you call phydio directly, either via 0x144 in the BIOS or via 0x4010 in the diskrom. Kind regards, Alex Wulms -- Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever See my homepage for info on the *** XSA *** format http://www.inter.nl.net/users/A.P.Wulms MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
> And does DOS2 work with 64kb of Memory Mapper? No, DOS2 needs 128kB of Mapper. This is from the file environment.doc, that is in dos2info.lzh, which can be downloaded from the FAQ: When the DOS kernel is initialized it checks that there is the memory mapper in the system, and that there is at least 128k of RAM available. If the kernel has found at least one slot which contains 128k of the mapper RAM, it selects the slot which contains the largest amount of RAM (or the slot with the smallest slot number, if there are two or more mapper slots which have the same amount of RAM) and makes that slot usable as the system RAM. When there is not enough memory on the memory mapper, MSX-DOS 2 won't start. Grtjs, Manuel PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org/) PPS: Visit my homepage at http://www.sci.kun.nl/marie/home/manuelbi/ MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
On Tue, 23 Mar 1999, shevek wrote: > On Mon, 22 Mar 1999, Marco Antonio Simon dal Poz wrote: > > > On Mon, 22 Mar 1999, shevek wrote: > > > > > On Mon, 22 Mar 1999, Marco Antonio Simon dal Poz wrote: > > > > > > > For the most part of diskroms, DMA can be in page 1, because they have > > > > access to FDC through addresses 7FF8h-7FFCh and also BFF8h-BFFCh, and they > > > > transfer a small routine to F1BFh (or something like that) that allows a > > > > disk transfer to happen in page 1. > > > > > > Is that MSX-standard or just the case on many MSXs? > > > > The standard doesn't say anything about the method that the diskrom should > > use. So, it's just the case on many MSXs. The standard only says that the > > interface should use memory addresses to transfer data between CPU and > > FDC. > > Ok, but this means that using DMA in page 1 is against MSX standard, or > not? Given that the standatd doesn't say anything about this, it's not against the MSX standard! Greetings from Brazil! - Marco Antonio Simon Dal Pozhttp://www.lsi.usp.br/~mdalpoz [EMAIL PROTECTED] "Apple" (c) Copyright 1767, Sir Isaac Newton /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ 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?
On Mon, 22 Mar 1999, Marco Antonio Simon dal Poz wrote: > On Mon, 22 Mar 1999, shevek wrote: > > > On Mon, 22 Mar 1999, Marco Antonio Simon dal Poz wrote: > > > > > For the most part of diskroms, DMA can be in page 1, because they have > > > access to FDC through addresses 7FF8h-7FFCh and also BFF8h-BFFCh, and they > > > transfer a small routine to F1BFh (or something like that) that allows a > > > disk transfer to happen in page 1. > > > > Is that MSX-standard or just the case on many MSXs? > > The standard doesn't say anything about the method that the diskrom should > use. So, it's just the case on many MSXs. The standard only says that the > interface should use memory addresses to transfer data between CPU and > FDC. Ok, but this means that using DMA in page 1 is against MSX standard, or not? Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
On Fri, 19 Mar 1999, Laurens Holst wrote: > >> 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... > > > >How can 64kb of RAM be memory mapper? Memory Mapper with only 4 memory > >blocks is a bit unuseful! > > NOT!!! With a non-memorymapped 64k RAM the blocks are on fixed adresses. If > a small game for example executes from #C000, and it has the fielddata at > #8000. Well if you include a music-replayer which uses the area #8000 for > music-data, then you can switch the music-data to that adres with > memory-mapped RAM, but you can't do that with non-memorymapped 64k RAM... So > now you understand that 64k mapped and 64k fixed are not the same? All right, I used to do some LDIRs, but now I see that the big deal is some kind of "hardware data transfer". Conclusion: the utility is a "high speed data transfer" between memory pages. I agree with you, it is useful, but not too much. Greetings from Brazil! - Marco Antonio Simon Dal Pozhttp://www.lsi.usp.br/~mdalpoz [EMAIL PROTECTED] "Apple" (c) Copyright 1767, Sir Isaac Newton /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ 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?
On Thu, 18 Mar 1999, jam wrote: > Hi, Marco Antonio > > >> 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... > MP> > MP> How can 64kb of RAM be memory mapper? Memory Mapper with only 4 memory > MP> blocks is a bit unuseful! > > Why do you think it's unuseful? Because the main function of Memory Mapper is to enable access to more than 64kb of RAM in a single slot. > For example, it's very useful for accessing the entire RAM using only the > #8000-#BFFF segment. My MSX2 has 64kb of standard RAM and to access other pages I used to do some LDIRs (i.e., I can handle that). > And DOS2 *needs* the memory to be mapped in order to manage the RAM properly. And does DOS2 work with 64kb of Memory Mapper? Greetings from Brazil! - Marco Antonio Simon Dal Pozhttp://www.lsi.usp.br/~mdalpoz [EMAIL PROTECTED] "Apple" (c) Copyright 1767, Sir Isaac Newton /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ 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?
On Mon, 22 Mar 1999, shevek wrote: > On Mon, 22 Mar 1999, Marco Antonio Simon dal Poz wrote: > > > For the most part of diskroms, DMA can be in page 1, because they have > > access to FDC through addresses 7FF8h-7FFCh and also BFF8h-BFFCh, and they > > transfer a small routine to F1BFh (or something like that) that allows a > > disk transfer to happen in page 1. > > Is that MSX-standard or just the case on many MSXs? The standard doesn't say anything about the method that the diskrom should use. So, it's just the case on many MSXs. The standard only says that the interface should use memory addresses to transfer data between CPU and FDC. Greetings from Brazil! - Marco Antonio Simon Dal Pozhttp://www.lsi.usp.br/~mdalpoz [EMAIL PROTECTED] "Apple" (c) Copyright 1767, Sir Isaac Newton /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ 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?
On Mon, 22 Mar 1999, Marco Antonio Simon dal Poz wrote: > For the most part of diskroms, DMA can be in page 1, because they have > access to FDC through addresses 7FF8h-7FFCh and also BFF8h-BFFCh, and they > transfer a small routine to F1BFh (or something like that) that allows a > disk transfer to happen in page 1. Is that MSX-standard or just the case on many MSXs? Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
On Mon, 22 Mar 1999, shevek wrote: > On Fri, 19 Mar 1999, Laurens Holst wrote: > > > What if you want to load code (in Dos) from # using the BDos-routines??? > > Yup, right, you load it in #4000 and then switch it to #. > > I never tried, but as far as I know the DMA can never be in page 1, since > that is where the disk-rom is switched during the actual reading > process... You can load it to #8000, of course :-) For the most part of diskroms, DMA can be in page 1, because they have access to FDC through addresses 7FF8h-7FFCh and also BFF8h-BFFCh, and they transfer a small routine to F1BFh (or something like that) that allows a disk transfer to happen in page 1. Greetings from Brazil! - Marco Antonio Simon Dal Pozhttp://www.lsi.usp.br/~mdalpoz [EMAIL PROTECTED] "Apple" (c) Copyright 1767, Sir Isaac Newton /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ 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?
On Fri, 19 Mar 1999, Laurens Holst wrote: > What if you want to load code (in Dos) from # using the BDos-routines??? > Yup, right, you load it in #4000 and then switch it to #. I never tried, but as far as I know the DMA can never be in page 1, since that is where the disk-rom is switched during the actual reading process... You can load it to #8000, of course :-) Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
64K VRAM?
Hi, Marco Antonio >> 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... MP> MP> How can 64kb of RAM be memory mapper? Memory Mapper with only 4 memory MP> blocks is a bit unuseful! Why do you think it's unuseful? For example, it's very useful for accessing the entire RAM using only the #8000-#BFFF segment. And DOS2 *needs* the memory to be mapped in order to manage the RAM properly. Salidos, digo ... Saludos. JAMcn ([EMAIL PROTECTED]) Apdo. Correos 3294 18080 Granada ... MSX MSX MSX MSX MSX MSX MSX MSX MSX MSX MSX MSX MSX MSX MSX MSX MSX MSX 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/)
Re: 64K VRAM?
>But the main utility of the Memory Mapper is to create a block switching >system that allows the slot to contain much more than 64kb of RAM. Using >Memory Mapper only to exchange memory contents isn't a big deal, because >you still can do it using LDIR (or using a famous technique called swap, >like this:) Not true to my opinion. What if you want to load code (in Dos) from # using the BDos-routines??? Yup, right, you load it in #4000 and then switch it to #. Besides, believe me, moving 16k using LDIR is MUCH slower than a simple 12-T-states-long OUT-instruction. LDIR is slow... >Of course Memory Mapper if much faster, but it's not much flexible, >because the block size to be exchanged is fixed in 16kb. If you want to >change 8kb basic programs, you'll need to use the above technique. Copying is not the main use, ofcourse not. But, as I stated before, if you write a .BIN-program for Basic, then you might not want to switch page 0 away to use the lowest 16k of RAM because then you switch away the interrupt. Then switching it to page 1 or 2 is much easier. >Is there a program that takes profit of the 64kb memory mapped? Absolutely. Track, for example, works with 64k (if you don't load any music). But it doesn't 'remove' page 0 because it doesn't want the BIOS-interrupt to be disabled. So it switches page 1... ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
>> 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... > >How can 64kb of RAM be memory mapper? Memory Mapper with only 4 memory >blocks is a bit unuseful! NOT!!! With a non-memorymapped 64k RAM the blocks are on fixed adresses. If a small game for example executes from #C000, and it has the fielddata at #8000. Well if you include a music-replayer which uses the area #8000 for music-data, then you can switch the music-data to that adres with memory-mapped RAM, but you can't do that with non-memorymapped 64k RAM... So now you understand that 64k mapped and 64k fixed are not the same? Ok. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: 64K VRAM?
On Thu, 18 Mar 1999, Marco Antonio Simon dal Poz wrote: > Is there a program that takes profit of the 64kb memory mapped? There once was a basic-database that used the mapper. I guess it worked with 64kB as well... Most flexible memory programs do, I think. The memman filecopier BK does... I wrote some string management routines that use all memory it finds in page 2 and 1 page in page 1, so that would also be of more use when it has a mapper. I think there are many other programs. Bye, shevek --- Visit the internet summercamp via http://polypc47.chem.rug.nl:5002 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?
On Thu, 18 Mar 1999, shevek wrote: > On Wed, 17 Mar 1999, Marco Antonio Simon dal Poz wrote: > > > How can 64kb of RAM be memory mapper? Memory Mapper with only 4 memory > > blocks is a bit unuseful! > > Not at all. With a mapper every 16kB page can be switched on , 4000, > 8000 or C000. This is useful for example when you want to use a lot of > memory under BASIC. You can lift the bottom of your program to C000 (F676 > if I remember correctly) and then use page 2 as data-area. With a 64kB > mapper this still gives you 48kB to use, in stead of the 16kB you would > have without a mapper. Yes, it's F676h that points to the bottom of the basic program. But the main utility of the Memory Mapper is to create a block switching system that allows the slot to contain much more than 64kb of RAM. Using Memory Mapper only to exchange memory contents isn't a big deal, because you still can do it using LDIR (or using a famous technique called swap, like this:) LD HL,source LD DE,destination LD BC,4000h LOOP: LD A,(HL) EX AF,AF' LD A,(DE) LD (HL),A EX AF,AF' LD (DE),A INC HL INC DE DEC BC LD A,B OR C JR NZ,LOOP RET Of course Memory Mapper if much faster, but it's not much flexible, because the block size to be exchanged is fixed in 16kb. If you want to change 8kb basic programs, you'll need to use the above technique. Is there a program that takes profit of the 64kb memory mapped? Greetings from Brazil! - Marco Antonio Simon Dal Pozhttp://www.lsi.usp.br/~mdalpoz [EMAIL PROTECTED] "Apple" (c) Copyright 1767, Sir Isaac Newton /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ 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?
On Wed, 17 Mar 1999, Marco Antonio Simon dal Poz wrote: > How can 64kb of RAM be memory mapper? Memory Mapper with only 4 memory > blocks is a bit unuseful! Not at all. With a mapper every 16kB page can be switched on , 4000, 8000 or C000. This is useful for example when you want to use a lot of memory under BASIC. You can lift the bottom of your program to C000 (F676 if I remember correctly) and then use page 2 as data-area. With a 64kB mapper this still gives you 48kB to use, in stead of the 16kB you would have without a mapper. Bye, shevek --- Visit the internet summercamp via http://polypc47.chem.rug.nl:5002 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?
On Wed, 17 Mar 1999, Alwin Henseler wrote: > > >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... How can 64kb of RAM be memory mapper? Memory Mapper with only 4 memory blocks is a bit unuseful! Greetings from Brazil! - Marco Antonio Simon Dal Pozhttp://www.lsi.usp.br/~mdalpoz [EMAIL PROTECTED] "Apple" (c) Copyright 1767, Sir Isaac Newton /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \ 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/)
