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/)
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/)
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/)
