Would this be worth the work?

First let me apologize if this post is in the wrong
forums section. this isn't a topic about the VP or
Magnavox Odyssey 2 games or about any new news or circumstances
on the website. so I hope I've chosen the correct forum.

for longer than the last decade, people have been
spoiled by such languages as:
Visual Studio
Java
Basic
and even C & C++

so many people have become accustomed to these higher
level languages that it has spoiled their ability to speak
low-level bare-bones languages (such as assembly)

So my question is - Would it be worth it to wright a
higher-level language for the Magnavox Odyssey 2?
essentially, the high level code would be broken down
to ASL and then passed through the compiler to create
Magnavox Odyssey 2 and VPack games.
The down side: likely to create bigger codes.
The up side: increased speed of programming and
increased number of individuals able to learn a
language that could create new games and tools for
our sweet vintage consoles.

I've written up a little example and more detailed
explanation of this idea and I hope you take the time
to look at the file:

LINK:
.RTF document hosted at Media Fire
(It would be written in VB6.0)

-Thanks

PS: I'm not committing myself to this (yet), I'm just considering the idea.

_________________
.

Cluck!

Try the new videopac forum http://www.videopac.org/forum

That's where more people are

_________________
You don't have to be mad, but it helps

Thanks, MJB.

_________________
.

Cluck!

I know that someone is already working on this (or has been working on it), but ran into some problems, especially with regards to page breaks: one of the difficulties with the 8048 microcontroller is that conditional jumps can only jump to a location within the current ROM page (a page is 256 bytes).

The maximum size of a program is 8 kB, but if your program is larger than 2 kB you'll need to use bankswitching.

Currently there are only a few Odyssey2/Videopac programmers, so if this tool would bring in more programmers it would be very welcome!
Since I already know how to program in assembler I wouldn't use it.

If you want to continue with this, I will help you if you have any questions about ASL, the 8048 or the Odyssey2 hardware.

The videopac.org account hasn't been approved yet so i suppose i'll be continuing the discussion here for maybe a few more days. (i'm guessing the approval admins are tied up with the holiday season.)

	Rene_G7400 wrote:
	I know that someone is already working on this (or has been working on it), but ran into some problems, especially with regards to page breaks: one of the difficulties with the 8048 microcontroller is that conditional jumps can only jump to a location within the current ROM page (a page is 256 bytes).

So long as all routines are kept under 256 bytes, this doesn't seem to be a problem.
Simply, during the translation process, break the code into routines under 256bytes.
don't put more routines in a page then will fit.
have a value that determines how many pages foward to jump.
at the start of a page

	Code:
	---------------------- STARTOFPAGELABEL[i]n[/i] if JumpToNextPage > 0 Then (i speak basicks a hell of a lot easer than i do asms) JumpToNextPage = JumpToNextPage -1 GOTO ENDOFPAGELABELn End if code...... ENDOFPAGELABEL[i]n[/i]

the only problem would be jumping BACKWORDS a page when the code only flows foward.
but there should be a solution for that somewhere. (after all, it only took me 2 secs to think of
the forward problem - perhaps you can jump out of a page if you specify a specific address such as bank switching?)

	Rene_G7400 wrote:
	The maximum size of a program is 8 kB, but if your program is larger than 2 kB you'll need to use bank switching.

i have a basic understanding of BANK SWITCHING and, actually, it makes me wonder if that can solve the page problem (as mentioned above - stating a memory address instead?) one can simply, and intentionally, make the translated program 3K minimum and use bank switching to jump back and forth through pages using the bank switching method. (would that work? the info on the above link make it APPEAR as though it would work.)

	Rene_G7400 wrote:
	Currently there are only a few Odyssey2/Videopac programmers, so if this tool would bring in more programmers it would be very welcome! Since I already know how to program in assembler I wouldn't use it. If you want to continue with this, I will help you if you have any questions about ASL, the 8048 or the Odyssey2 hardware.

Thanks.

the biggest problem would be the fact that I'd only have a few hours a week to work on it. (my wife gets real jealous of me spending 30 mins on the computer and ignoring her, but to be fair I'm just as bad.)

BTW - i have a book on Assembly Language 8086. Should i ignore it while i'm trying to get down 8048 or does enough carry over to the 8086 chips to make it useful?

_________________
.

Cluck!

I don't think that the 8086 assembly language will help you much with learning 8048 assembly. The 8048 is a quite simple microcontroller (not a microprocessor), so if you understand the basics of assembly code in general, it should not be difficult to learn 8048 code.

Some remarks about the address space of the 8048:
000 - 3FF : internal ROM (BIOS) of the 8048 (4 pages)
400 - FFF : external ROM (12 pages)

So the 8048 can address a maximum of 4kB. Since (unconditional) CALL and JUMP instructions can only contain 11 address bits, the 12th address bit is cleared or set by the SEL MB0 / SEL MB1 instructions.

When you number the address lines from A0 to A11 (A11 being the most significant address bit), then address bit A10 is not used by most cartridges (and unavailable if the Voice module is used). The result is that the external ROM can only be 2kB instead of 3kB. (4 pages in MB0 and 4 pages in MB1.)

Two outputs of the 8048 (P1.0 and P1.1) are connected directly to the most significant address bits of an 8kB external ROM, so when you set or clear these outputs in your program, the 8048 starts reading data from an other 2kB bank directly. As far as I know ASL can not handle this strange situation, so you'll have to write four 2kB programs and keep track of the bank switching yourself.

Hum... very hard task indeed.
I see why this idea ran into problems earlier.
it sound best for me to put the BO2 concept on hold
until i finish learning how to program for the 7400.

Thanks for the Guru help, Rene. Very Happy

_________________
.

Cluck!