In 2002 there came idea among people to start developing a new kind of MSX hardware test system to improve MSX emulator quality controll, to test failing MSX hardware and to find possible causes of software not to work. This caused MSX Benchmarking, Information and Testing System (MSX-BITS) project to be launched.

The project team made a standard for generating MSX tests, that could be combined to testkit. However after generating working standard and test engine the project was stopped because of lack of time and intrests. Now it is time to get the project up and running again and that is, where we need your help!

The main thing this project needs is a WEB portal developer and after this we will need a place to host our site

Here is a definition, what kind of page this project needs:

- We will need a page, where you can suggest a new tests to different categorys and where you can assingn implementing a test for your self. This is to avoid accidential double work and to see, who else is working on same category.

- We will need a forum, where you can attach files as well as discuss about working of your module/library. This way module/library developers can get feedback from other developers and MSX-BITS admins. When the module meets all the MSX-BITS requirements, it will be added to MSX-BITS disk image.

If you think, you would like to help, shout out loud or send mail for example to me.

If we get a project page, next things we will need are:

Test selection menu programmer(s). Test selection menu is a program where you can select different tests, you want to run by manual selection or by category like "Select all noninteractive tests", "run all CPU tests" etc. This program should give this information to MSX-BITS engine, so this is just a front end. Current BASIC program can be used as base and there can be even different kind of menus, that can be selected. First thing we anyway need is just working basic menu for MSX1.

After tests are completed, it would be nice, if there would be also result viewer, so we also need Result viewer programmer(s). This can be really simple MSX1 text file viewer, complex graphical Megareport look a like for MSX tR or a program that just counts, how many points this machine / emulator got.

Most important things are anyway Test program developers and Library developers that in last phase will make it all working!


If you want to know more about MSX-BITS project, read the following technical definition of MSX-BITS modules. Current MSX-BITS engine supports all the documented features:

MSX-BITS:
---------
(Note: These definitions can still change without further notice)


- Minimum requirements for testkit is MSX1 with 64Kb memory and diskdrive

- Test kit memory layout
	#0000-#3FFF RAM available for tests. (ML) This area has MSX-BIOS when entering to test routine.
	#4000-#7FFF RAM includes X-BASIC. This area has MSX-BASIC when entering to test routine.
	#8000-#CFFF RAM available for tests. (BASIC, X-BASIC & ML)
	#D000-#FFFF RAM testkit internal code & variables. / internal variables of MSX-BASIC

- New tests are added to Main menu by adding following kind of line to correct place

	DATA <basic load address in HEX>,<test file name without .000 extention>

	Example:

	190 DATA 8000,PSG_TST1

- Librarys are well documented assembler programs, that can use "available for tests" space.

- Librarys are ment for writing code, that is needed by more than one test routine (Like correct VDP access)
- Library files are BLOAD able ML files that are named as *.LIB

- Library source must start with following information:
	- Library purpose
	- Memory area used for loading library
	- Memory area used while using library commands
	- Commands in library & access points.

- All tests that use any hooks must return them to original state.
- All tests must use only MSX1 BIOS routines or MSX1 compatible BASIC. (For loading a picture to VRAM etc. use librarys or test kit internal commands.)
- In tR test will always start in Z80 mode.
- If DOS2 is found, direct access to memory is allowed. (MAP2 loaded)
- When test routine starts or leaves screen should be configured following way:
	screen 0,,0
	width 40
	color 15,0,0
	key off
	cls

- VDP should be returned to this default configuration after test with default interrupts enabled, screen enabled etc.

- Interactive tests should print detailed information about test being performed to screen before test and ask success after actual test.

- Interactive test should accept following commands as input:
	Y or y	Test did run correctly
	N or n	Test did not run correctly
	A or a	Run this test again
	Esc	Return to main menu.

- Test must output results to file in following format:

	Test name = result
	"#" starting lines include short descrpition of test. Can be multible lines
	"##" starting lines includes detailed descrpition of test in following format:
		## Required correctly functioning hardware for this test:
		## - <item 1>
		## - <item 2>
		...
		## - <item x>
		##
		## <Free detailed description of this test (can be multible lines)>


- Test should always return to BASIC when reporting is done. (Hooked loader will take test to next phase)

- All files must be closed when actual test is performed in any of following conditions:
	- Test takes more than 1 second.
	- Test may cause computer to hang or reboot
	- Test is interactive

- Tests should always use following ports for accessing hardware:

	#98-9B VDP (or MSX1-BIOS)
	#7C-7D FM-PAC (or FM-BIOS if found)
	#A0-A3 PSG (or MSX1-BIOS)
	#B4-B5 RTC
	#C0-C3 MSX-AUDIO 1 & 2
	#D8-DB KANJI ROM
	#FC-FF Memory mapper (or DOS2 if found)

- In BASIC folowing USR commands are reserved:
	USR8	(Function number)
	USR9	(Parameter)

- USR6 & USR7 recommended for library use

- If test routine uses USR8 or USR9 commands for any other purpose, they need to be restored before end of test proggram.

- BASIC test file, that is loaded by main menu is always <filename>.000 If routine needs to load some other files they must be named .001 .002 etc.

- Tests should always read 8 byte long filename from USR function and add extention if it needs to load some sub routine. (This allows renaming afterwards)

- Special memory locations:

	#D000	(R)	#FF = Computer was hanged or rebooted (Always check this and reset this to zero, when handled)
			#00 = Normal Run

	#D001	(R)	#00 = Raport everything
			#01 = Skip raport if hardware is not found correctly
			#02 = Raport only if test fails or gives non typical value

	#D002	(W)	#FF = Test was aborted. Return to main menu.
			#00 = Continue to next test

	#D003	(R)	#00 = TMS9918 / TMS9928 detected
			#01 = V9938 detected
			#02 = V9958 detected

	#D004-#D00F     = Reserved for future expancion
	#D010		= testkit functions jump table


Usage of internal USR functions:


	You don't need to specify function number if you use string as a parameter for USR9 Parameter lenght defines what kind of string is returned and USR8 parameter is not changed.

	USR9("12345678")		Returns filename body. This should be used if other files need to be loaded by test routine.

		Example:

		10 F$=USR9("12345678")
		20 BLOAD F$+".001",&HC000
		30 BLOAD F$+".002",R

	USR9("12345678.ABC")		Returns filename that is used for writing test results. You must take care, that information is only added to this file and it is done correctly.

		Example:

		110 OPEN USR9("12345678.ABC") FOR APPEND AS #1
		120 PRINT #1,""
		130 PRINT #1,"Z80: Readed databusvalue =";DB$
		140 PRINT #1,""
		150 PRINT #1,"# This value represents value, that is on databus, when Z80 leaves"
		160 PRINT #1,"# databus for peripherals. Normal value is #FF on MSX."
		170 PRINT #1,""
		180 PRINT #1,"## Required correctly functioning hardware for this test:"
		190 PRINT #1,"## - Z80 CPU"
		200 PRINT #1,"## - VDP interrupts"
		210 PRINT #1,"##"
		220 PRINT #1,"## If this value is not #FF that means, that it will cause problems"
		230 PRINT #1,"## on programs, that use IM1 or IM2 mode instead of normal IM0 mode."
		240 PRINT #1,"## This is anyway a rear situation. If ERROR was returned this means,"
		250 PRINT #1,"## that your computer hanged/rebooted during test and that this value is"
		260 PRINT #1,"## changing between interrupts."
		270 PRINT #1,"##"
		280 PRINT #1,"## On error check following test results:"
		290 PRINT #1,"## - Interrupt mode 2 test"
		300 PRINT #1,"## - VDP interrupt test"
		310 CLOSE #1

	If any other lenghts (than 8 or 12) are used to input sting to USR9 "Illegal function call" error will be returned.
	NOTE! : USR9(string$(8," ")) type of tricks are illegal and may cause unwanted results.

	R=USR8(0):R=USR9(A)		Call routine in RAM in address A. (Interrupts are disabled during call)

	R=USR8(1):X=USR9(Y)		Returns Low byte (X) of word (Y)

		Example:

		R=USR8(0):PRINT HEX$(USR9(&H1234))
		34
		Ok

	R=USR8(2):X=USR9(Y)		Returns Hi byte (X) of word (Y)

		Example:

		R=USR8(1):PRINT HEX$(USR9(&H1234))
		12
		Ok

Quote:

The main thing this project needs is a WEB portal developer and after this we will need a place to host our site

/me waves

Hey, how I have managed to miss this!

Really cool!!! Vampier, you have been selected from all of the ardently jostle nominees!

Click <-- there to get my mail address. Or we can talk about the details in here as well... I understand web portal development about as well as earthworms understand about rocket science. Therefore you can propably tell me, how realistic those ideas about the www-page was? Can it be implemented like I defined up ^ there?

www.vampier.net
www.vampier.net/eggerland

for a few of my examples... or I can go XML aswell