Register - Login
Views: 99348594
 Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies		 04-21-22 05:23:13 PM
Jul - NO! GO TO STAR! - Stereoscopic 3D? New poll - New thread - Thread closed
Pages: 1 2 Next newer thread | Next older thread
OzOnE_2k10
Random nobody
Level: 6


Posts: 1/5
EXP: 737
For next: 170

Since: 05-24-10


Since last post: 11.9 years
Last activity: 11.0 years
Posted on 05-24-10 08:25:12 PM (last edited by OzOnE_2k10 at 05-24-10 05:37 PM) Link
Hi, all,

I tend to type alot, but I'll just throw all the info out there first then see what you guys / gals think?...

Firstly, I'm constantly amazed at the things that are now possible with ROM editing. It's also very nice to see that the N64 scene is still quite busy.

For a bit of an intro (if you want to read my very boring posts), I've also been helping to make a new PCB layout for the N64. This has been going on for many months though, and only one or two people that I know of have ever attempted to make an actual PCB so far (not me, yet)...

http://benheck.com/forum/viewtopic.php?p=324205#p324205

OK, back on topic - For many years now, I've been toying with the idea of using two N64's for producing the Left / Right eye image (and a pair of LCD shutter glasses) for true stereoscopic 3D. (yep, I'm serious)...

EDIT: I realize that you can already use 3D shutter glasses with PJ64 (not Red / Blue glasses - yuck!), but I'd love to use the real hardware...

The idea is that you use two copies of the same game, but one ROM is kept unpatched (use it for the Left eye for example), and the other ROM is patched so that the camera is shifted and rotated very slightly to produce the image for the Right eye.

This will require a bit of electronics to merge the two images together and output either 120Hz (60Hz per Left / Right image), or Left / Right interlaced 3D format.

120Hz would obviously require VGA output or similar, and the ROMs video tables would need patching for progressive. Interlaced 3D wouldn't be too difficult though.

(controlling the glasses is easy, and I've already built a controller for this.)

The main problem of course is keeping both consoles perfectly in sync, and also routing the PIF responses from the "master" N64 to the slave so that only one set of controllers were used.

I've done some testing on this already, and I had a small amount of success with running two N64's from the same PIF and clock signals. This would work randomly at power-up because the phase of one clock would often "flip" polarity.

When it did work though, I could actually use the controller on the "master" N64 for a while in Goldeneye (until it would freeze). This is due to the clocks still being slightly out-of-phase, so it needs an extra circuit to distribute ONE set of master clocks to both consoles.

Anyway, that comes later (if it will work at all). The reason I posted on here is to ask about how I could patch a ROM so that the camera is permanently shifted sideways very slightly, or the world / model view is rotated slightly to mimic the eye parallax effect so the 3D glasses would work??

I've already tried patching the MESS source so that it shifts the viewport to the left when it reads the matrix from DMEM (most of the text stays in the correct place though). The result is like image below (yes, I know the polygons look bad, but that's a WHOLE other topic. lol)...

http://img80.imageshack.us/img80/4466/marioshiftedozone.jpg

This type of "patch" would only work on an emulator though, so what I really need to know is if it's easy enough to patch the actual ROM itself to shift / rotate the camera? (or modelview / "World")?

Oh, I don't know... Maybe use the extended ROM of Mario perhaps?

I know only the basic stuff about 3D matrix manipulations and my knowledge of C coding isn't amazing, but I guess that this would require the projection matrix to be multiplied by a rotation matrix (unless you can tweak the camera values directly?)

So, a lot of this is theory atm, but I'm sure it could be made to work as long as I can get the consoles to keep sync.

Thanks for reading.
OzOnE.
Tanks

360? Yessum.
Level: 121


Posts: 4038/4170
EXP: 19787440
For next: 269256

Since: 07-10-07

From: VA

Since last post: 9.5 years
Last activity: 9.5 years
Posted on 05-24-10 08:29:23 PM Link
I am amazingly intrigued by this. I'd love to see how this turns out for you. Might have to go dig up my old goggles from 8th grade geology.

____________________
Lyskar
12210
-The Chaos within trumps the Chaos without-
Level: 192


Posts: 5597/12211
EXP: 99215022
For next: 658549

Since: 07-03-07

From: 52-2-88-7

Since last post: 7.4 years
Last activity: 7.3 years
Posted on 05-24-10 08:44:16 PM Link
Stats
Time/Date
05-24-10 02:44:16 PM
Posts
5597
Days Here
1056
Level
109
Metal_Man88's Post
Normally I would shunt this off and say 'post in the project thread, then the help one' but this appears to be a strange combination of new way of editing the ROM to make 3D stuff rather than 'OMGZ MARIO IZ GREEN WITH BLOODSHOT EYEZ' so I'll let it stay.

Especially since the idea is kind of intriguing, though I wonder how you avoid desyncs with both ROMs running at once, especially with things that use RNGs.

____________________
Don't let an old saying get in the way of a good idea.
Eisnaught - SSQ² - Mobius Roleplay - SSS
Sukasa

Level: 123


Posts: 2451/4326
EXP: 20913325
For next: 317941

Since: 07-07-07


Since last post: 1.1 years
Last activity: 1.0 years
Posted on 05-24-10 09:08:10 PM Link

Any RNG is just a simple math equation, so assuming the carts have perfectly identical data there'll be no issue with that since the N64 doesn't keep stuff like a clock, etc.

____________________
<@Bitmap> Be completely humble and gentle;
<@Bitmap> And tell them to shut the fuck up
Xkeeper

Level: 263


Posts: 16413/25343
EXP: 296648011
For next: 2312442

Since: 07-03-07

Pronouns: they/them/????????

Since last post: 6 days
Last activity: 14 hours
Posted on 05-24-10 09:15:35 PM Link
Originally posted by Sukasa
Any RNG is just a simple math equation, so assuming the carts have perfectly identical data there'll be no issue with that since the N64 doesn't keep stuff like a clock, etc.

Wrong. Many RNGs use human input as well to help make the output more chaotic.

This is why luck manipulation in TASes exists.

____________________
Sukasa

Level: 123


Posts: 2452/4326
EXP: 20913325
For next: 317941

Since: 07-07-07


Since last post: 1.1 years
Last activity: 1.0 years
Posted on 05-24-10 09:16:35 PM (last edited by Sukasa at 05-24-10 06:16 PM) Link

Seeing as both games would be getting identical controller input in this scenario, I disregarded that.

____________________
<@Bitmap> Be completely humble and gentle;
<@Bitmap> And tell them to shut the fuck up
OzOnE_2k10
Random nobody
Level: 6


Posts: 2/5
EXP: 737
For next: 170

Since: 05-24-10


Since last post: 11.9 years
Last activity: 11.0 years
Posted on 05-24-10 09:39:37 PM Link
Hi,

Actually, I never gave proper thought to the randomness factor. Even it's pseudo-random, it might be random in the practical sense?

The main goal is to make sure that one of the N64's doesn't drop frames though (purely because it will be drawing slightly different data / number of polys).

Also, the PIF request have to stay identical, because it will only work assuming that both consoles request the same PIF command at the same time, but only the master N64's PIF will return the data to the slave RCP (and to itself). Again, the PIF clocks will need to stay in sync, but the same applies to the PIF clock as it does to the RCP hopefully.

The problem with keeping the clocks in sync is due to the use of the PLL chips. It would probably have a chance of working if I could take the clocks from the output side of the master N64's PLL chips and route them to the slave. I tried this though, and it's just dies (wrong impedance etc.) So, the clock outputs will need some buffers, then route them directly to the slave's RCP / RDRAM.

Or, just generate the clocks directly from the FPGA and use resistor dividers for the RDRAM clock (it needs to be a certain voltage / offset). The video / audio clock is just TTL (3.3v level).

I'm hoping the RCP uses a simple clock divider internally to produce the main clock from the Rambus clock (ie. 250MHz / 4 = 62.5Mhz) instead of a PLL. I need to check if both consoles have the same startup time too (that they start up after the same number of clocks when they're brought out of reset).

I'll be able to play with this stuff more in the coming weeks, as I'm buying a much better FPGA kit next week - the same kit as Marshall is using to develop his cool CF card emulator (sorry if this is off-topic, but it might be a news flash for some)...

http://www.youtube.com/watch?v=uYAowmP1OEM

OzOnE.
P.S. Another idea, which WOULD be possible and fairly straightforward: generate four seperate video outputs from one N64 with each output zoomed in to one-quarter of the screen. This would let multiple players use a separate TV for things like Mariokart / Goldeneye etc.
DarkSpacer
Member
Level: 30


Posts: 26/184
EXP: 165782
For next: 87

Since: 03-23-10


Since last post: 5.6 years
Last activity: 5.0 years
Posted on 05-24-10 10:09:07 PM Link
This would be kind of hard. THe 3D glasses idea I mean, because if you shift the camera over, you MIGHT have one console rendering, say, 30 polygons, and the tilted camera one renders 40 polygons, and 30 polygons, as an example, is the maximum it can render before it slows down. That would mean the 40 polygon camera is moving as a slower frame rate, and it will break the 3D look.

As for the zooming-down-to-1/4-of-the-screen thing...what if you were playing four Mario Karts all with the "All Players Can Be the Same Character" cheat on Vs. on Rainbow Road?

It won't be pretty.
Lyskar
12210
-The Chaos within trumps the Chaos without-
Level: 192


Posts: 5599/12211
EXP: 99215022
For next: 658549

Since: 07-03-07

From: 52-2-88-7

Since last post: 7.4 years
Last activity: 7.3 years
Posted on 05-24-10 10:14:54 PM Link
Stats
Time/Date
05-24-10 04:14:54 PM
Posts
5599
Days Here
1056
Level
109
Metal_Man88's Post
Hm, yeah, the only way to keep them even would be to, like, force it to render offscreen polygons and always render the same amount of polygons... sounds messy.

____________________
Don't let an old saying get in the way of a good idea.
Eisnaught - SSQ² - Mobius Roleplay - SSS
OzOnE_2k10
Random nobody
Level: 6


Posts: 3/5
EXP: 737
For next: 170

Since: 05-24-10


Since last post: 11.9 years
Last activity: 11.0 years
Posted on 05-24-10 10:33:31 PM Link
"All Players Can Be the Same Character". lol

I suppose it wouldn't be much fun, but it would be nice to see, and would at least stop people peeking at your play screen to see where you are. (Damn, I hated that on Perfect Dark back in the day).
Or, you could just use cardboard on the TV instead.

Yep, the slow-down problem is the big show stopper for the 3D idea. Not only will it drop a frame and go out of sync, but the CPU will also halt while it's waiting for the RDP to finish drawing.
That then would mess up the rest of the sync and the slave console would probably crash. The master console should keep on playing, because it would be in full control of the PIF etc.

An easier thing to test is to just convert some homebrew code to output stereo 3D. Although, with only arround 30Hz per eye, it would flicker like hell. Could do interlaced maybe?

I'll keep working on it though. You might tell from my posts on benheck and dextrose that I'm quite determined...

We're getting quite close to building an N64 portable with a built-in CF card slot. Hopefully, it will have some other goodies, like: RGB output from any generic N64 chipset, auto PIF code switching for NTSC / PAL ROMs, and save-game management to and from CF etc.

OzOnE.
Joe
Common spammer
🍬
Level: 111


Posts: 1357/3392
EXP: 14485583
For next: 382777

Since: 08-02-07

From: Pororoca

Since last post: 19 hours
Last activity: 2 hours
Posted on 05-25-10 12:01:36 AM Link
To heck with RGB output, may as well rig it up to DVI.

Actually, I'd like to do that myself but I have no idea where to begin. I know a decent amount about the various signal protocols that would require, but I have no idea what kind of FPGA to use (or how I would assemble it without access to soldering tools).

____________________
fin
DarkSpacer
Member
Level: 30


Posts: 27/184
EXP: 165782
For next: 87

Since: 03-23-10


Since last post: 5.6 years
Last activity: 5.0 years
Posted on 05-25-10 12:08:21 AM (last edited by DarkSpacer at 05-24-10 09:14 PM) Link
I meant it would be 16 screens on the same TV, and 16 of the same player, on a course where much of the track looks the same. I'd just hope to God I'll remember who I am

Edit: oopsie I meant to add all the games are in four player mode too. Oh well, It still won't be pretty.
messiaen
Catgirl
Level: 68


Posts: 867/1085
EXP: 2593488
For next: 135312

Since: 11-20-07


Since last post: 8.1 years
Last activity: 7.2 years
Posted on 05-25-10 02:54:06 AM Link
Unfortunately, we don't know that much yet about the camera on SM64. There are multiple camera settings and structs, and sometimes the game shifts between different cameras (each with their particular settings) so a LOT of code would have to be rewritten (which could maybe increase the sync problems?).

My bet is that you should look at some of the gu (Graphical Utilities) UltraLib functions (guPerspective and guPerspectiveF may perhaps give you some control about what you're looking for). I know very little about actual N64 programming, so perhaps Marshall could give you some help on this.

One thing you should definetely check is Nagra's Mario Resource (you can find it at the Dextrose forum), which may help you navigate through the game code. There's also a master.cod file included which lists address for some of the UltraLib gu functions.
OzOnE_2k10
Random nobody
Level: 6


Posts: 4/5
EXP: 737
For next: 170

Since: 05-24-10


Since last post: 11.9 years
Last activity: 11.0 years
Posted on 05-25-10 09:23:20 PM (last edited by OzOnE_2k10 at 05-25-10 06:51 PM) Link
Damn it! (sorry). I just clicked on the stupid favorites bar by accident, and wiped out my original post (don't you hate it when that happens - should have used Notepad instead).

I'll try again.

I looked into the Ultra 64 libraries and found the guPerspective / memmove / matrix stuff, but I have no idea how to find these in the actual ROM assembly? I also didn't have much luck trying to find Nagra's resource on the Interweb (is Dextrose dead now? I know it used to be dextrose-forum(s)?). From what I recall, the "master.cod" file worked with IDA Pro... I have a copy of that, so I'll try to find Nagra's resource. I know I downloaded it months ago, so it must be on this PC somewhere (hiding amongst 30,000 files).

As for the 3D sync stuff - I tidied up the wiring a lot last night (using shorter power wires and short sheilded coax for the clocks). I'm now using a PC PSU as well - I didn't realize the N64's need around 2 Amps EACH (with expansion paks), and I was trying to run both console from one N64 PSU originally!!

I managed to get the slave console running from the master console's Rambus clock. The problem is, as soon as you plug the jumper pak into the master console, the slave crashes / won't boot. The reason for this is due to the fussy Rambus voltage levels...

The Rambus RSL signalling protocol uses very small voltage swings for the logic (around 0.6V). The higher voltage level on the N64 is VTERM (around 2.56v). VREF is low level for the logic, and is around 1.9V.
The clock is biased at around 1.7V normally, but when you plug the expansion pak into the master console, the resistances / impedances of both console is paralleled. This halves the resistance, and the clock offset rises to around 2.2V!! This obviously kills the Rambus communication on both consoles.

So, it will need either a simple potentiometer to adjust the offset so the clock bias is around 1.7V when both consoles are connected, or it might require a buffer, which will take a while for me to put together. phew.

I actually tried outputting HDMI from an N64 a few months back. I used an FPGA and wrote some code to convert from the RCP output format to bt.656 (the type of digital video protocol used in most DVD players and sat boxes etc.). The HDMI chip was on a board from a cheap Sumvision HDMI upscaling DVD player (I bought 10 broken players very cheap on eBay and got 6 working)...

It did get some scrambled N64 image on the monitor, but it was kind of garbaged horizontal lines. I'm 99% sure this is because the N64 outputs interlaced, and the HDMI chip expects progressive. I couldn't find a proper datasheet for the chip though, and my crappy FPGA board doesn't have the required SRAM / DRAM for doing the interlaced-to-prog conversion. I might into this again in the coming weeks after I've bought the new Altera kit.

My first mission is to get some new N64 PCBs made though....

http://forums.benheck.com/viewtopic.php?f=5&t=32430&start=420

A more modular concept is a much better idea, and means that I might at least get a small N64 board made first, then get the cart emu done after (with help from Marshall and Kibble hopefully).

OzOnE.
P.S. I will still very much be soldering and testing the 3D stuff too.
messiaen
Catgirl
Level: 68


Posts: 869/1085
EXP: 2593488
For next: 135312

Since: 11-20-07


Since last post: 8.1 years
Last activity: 7.2 years
Posted on 05-25-10 10:57:15 PM Link
Damn, dextrose-forum.com (I think that was the domain after the last move) seems to be down. It would be a real shame if nobody archived the forums/tools there.

If you don't find your master.cod file, you can use this version of IDA PRO (UltraLib signature files included). Just load a savestate of whatever version of Mario 64 you are using and it should find most UltraLib functions.

If you are using the US 1.0 version, here are addresses of gu functions from Nagra's master.cod file:

0x80324c20,guOrthoF
0x80324d74,guFrustum
0x80324de0,guPerspectiveF
0x80325010,guPerspective
0x803258d0,guRotateRPYF
0x80325924,guRotateRPY
0x80329450,guMtxF2L
0x80329550,guMtxIdentF

Nemu can be quite handy if you want to test doing some changes or check how these functions are called.
Joe
Common spammer
🍬
Level: 111


Posts: 1358/3392
EXP: 14485583
For next: 382777

Since: 08-02-07

From: Pororoca

Since last post: 19 hours
Last activity: 2 hours
Posted on 05-25-10 11:10:01 PM Link
Originally posted by OzOnE_2k10
I actually tried outputting HDMI from an N64 a few months back. I used an FPGA and wrote some code to convert from the RCP output format to bt.656 (the type of digital video protocol used in most DVD players and sat boxes etc.). The HDMI chip was on a board from a cheap Sumvision HDMI upscaling DVD player (I bought 10 broken players very cheap on eBay and got 6 working)...

It did get some scrambled N64 image on the monitor, but it was kind of garbaged horizontal lines. I'm 99% sure this is because the N64 outputs interlaced, and the HDMI chip expects progressive. I couldn't find a proper datasheet for the chip though, and my crappy FPGA board doesn't have the required SRAM / DRAM for doing the interlaced-to-prog conversion. I might into this again in the coming weeks after I've bought the new Altera kit.
Actually, interlacing is an option of the game. Most of the games I own only do progressive, and one of the few that does interlaced (Star Wars Episode 1 Racer) switches to progressive on occasion.

Besides that, I've read through the HDMI specs and both 240p and 288p are legal resolutions. You can look here and see for yourself. (Sections 6.3 and 6.4, on pages 87-88, are of particular interest.)

I'm plenty willing to help you out however I can.

____________________
fin
OzOnE_2k10
Random nobody
Level: 6


Posts: 5/5
EXP: 737
For next: 170

Since: 05-24-10


Since last post: 11.9 years
Last activity: 11.0 years
Posted on 05-25-10 11:29:53 PM Link
Thanks for that Messiaen. I should be able to hunt down something with the sig file (gonna be a long night).

It seems that Dextrose has been down for a few weeks now. I hope it's not gone for good.

Joe, I'm a bit confused tbh... AFAIK, the N64 games have only ever output interlaced? By definition, standard composite / RGB outputs are always interlaced.
Do some N64 games have an interlaced option? If so, that would only imply that the framebuffer was updated in a different way, but I've never seen an N64 output progressive before?

I'm sure there are plenty of HDMI chips out there which would take the signal from the N64 (once converted by the FPGA) and output to standard 480p (maybe even upscale for what it's worth).
The huge problem for me has always been 1. Do the PCB layout and Getting proper PCBs made, and 2. Finding the datasheets for the more obscure chips.

Although I'm very fussy when it comes to picture and sound quality (I'm THX certified, and also build audiophile stuff), I think RGB would be fine on the N64 since the resolution isn't exactly high enough to warrant HDMI tbh. It should be easy enough to output VGA though (Horiz and Vert sync is available on the N64), but the ROMs would need patching for progressive.


OzOnE.
Joe
Common spammer
🍬
Level: 111


Posts: 1359/3392
EXP: 14485583
For next: 382777

Since: 08-02-07

From: Pororoca

Since last post: 19 hours
Last activity: 2 hours
Posted on 05-26-10 02:43:19 AM Link
Originally posted by OzOnE_2k10
Joe, I'm a bit confused tbh... AFAIK, the N64 games have only ever output interlaced? By definition, standard composite / RGB outputs are always interlaced.
By definition, yes, but Nintendo still built the NES, SNES, and N64 to output progressive video.
Originally posted by OzOnE_2k10
Do some N64 games have an interlaced option? If so, that would only imply that the framebuffer was updated in a different way, but I've never seen an N64 output progressive before?
More likely you've never seen a N64 output interlaced before. Of the 19 games I have, two output interlaced: Pokemon Stadium 2 and Star Wars Episode 1 Racer. (The Star Wars game is not always interlaced; it will often switch to progressive.)
Originally posted by OzOnE_2k10
I'm sure there are plenty of HDMI chips out there which would take the signal from the N64 (once converted by the FPGA) and output to standard 480p (maybe even upscale for what it's worth).
Isn't 480i a standard too? HDMI allows the video signals from the N64 to be passed through directly, with nothing more than a pixel doubler. The N64's digital signal could be converted to HDMI on the FPGA and then passed off to an output amplifier.
Originally posted by OzOnE_2k10
The huge problem for me has always been 1. Do the PCB layout and Getting proper PCBs made, and 2. Finding the datasheets for the more obscure chips.
If the HDMI processing is done on the FPGA, you could probably simplify your PCB design. For that to work, it would be best to check if your FPGA is fast enough for HDMI at 480i. (That will also cover the more common 240p.)
Originally posted by OzOnE_2k10
Although I'm very fussy when it comes to picture and sound quality (I'm THX certified, and also build audiophile stuff), I think RGB would be fine on the N64 since the resolution isn't exactly high enough to warrant HDMI tbh. It should be easy enough to output VGA though (Horiz and Vert sync is available on the N64), but the ROMs would need patching for progressive.
- Digital displays frequently assume "standard" RGB/composite/what-have-you is always interlaced, and postprocess to that effect. Said postprocessing destroys progressive video.
- RGB isn't even an option here in North America.
- HDMI directly supports the resolutions the N64 is capable of. VGA would require scan rate conversion.
- Any games that use interlaced video do so because it allows for higher-resolution graphics. Patching games for progressive display completely defeats that.
- There are chips that will convert the digital audio signals from the N64 directly to S/PDIF.

I would love to build an HDMI converter myself, but I have no experience and no idea where to start. (And no soldering tools. And no money.)

____________________
fin
Rena
I had one (1) message in Discord deleted and proceeded to make a huge, huge mess about how it was a violation of free speech and how moderators are supposed to be spam janitors and nobody should have the right to tell me not to talk about school shootings
Level: 135


Posts: 3287/5390
EXP: 29044383
For next: 290622

Since: 07-22-07

Pronouns: he/him/whatever
From: RSP Segment 6

Since last post: 330 days
Last activity: 330 days
Posted on 06-01-10 05:51:38 AM Link
06-01-10 12:51:38 AM
Post #3287
Hm, instead of trying to keep two different scenes precisely in sync, could you overclock one console to squeeze 120hz out of it? Then you'd probably just need to hack the main game loop to render each frame twice, with the second's camera adjusted slightly. There was a Chinese N64 (official, but very different) that ran at double speed and the games just went faster with no issues.

BTW I'm very interested in building an N64 cartridge emulator and getting VGA/HDMI output from one. (Digital sound would be neat too. )

____________________


[loading witty comment...]
why not?
Joe
Common spammer
🍬
Level: 111


Posts: 1370/3392
EXP: 14485583
For next: 382777

Since: 08-02-07

From: Pororoca

Since last post: 19 hours
Last activity: 2 hours
Posted on 06-03-10 12:55:04 AM Link
Originally posted by HyperHacker
There was a Chinese N64 (official, but very different) that ran at double speed and the games just went faster with no issues.
I find that to be a rather dubious claim, although the best I have to go off of is a promotional video from the official website.
Originally posted by HyperHacker
BTW I'm very interested in building an N64 cartridge emulator and getting VGA/HDMI output from one. (Digital sound would be neat too. )
I'd be glad to help you with that, although I'd much rather build them myself.

____________________
fin
Pages: 1 2 Next newer thread | Next older thread
Jul - NO! GO TO STAR! - Stereoscopic 3D? New poll - New thread - Thread closed


Rusted Logic
Acmlmboard - commit 47be4dc [2021-08-23]
©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al.

34 database queries, 10 query cache hits.
Query execution time:  0.086618 seconds
Script execution time:  0.046702 seconds
Total render time:  0.133320 seconds


TidyHTML vomit below
line 1 column 1 - Warning: missing <!DOCTYPE> declaration
line 2 column 300 - Warning: unescaped & or unknown entity "&page"
line 119 column 11 - Warning: <form> isn't allowed in <table> elements
line 118 column 10 - Info: <table> previously mentioned
line 120 column 11 - Warning: missing <tr>
line 120 column 119 - Warning: missing </font> before </td>
line 124 column 16 - Warning: plain text isn't allowed in <tr> elements
line 120 column 11 - Info: <tr> previously mentioned
line 125 column 68 - Warning: missing </nobr> before </td>
line 141 column 68 - Warning: missing </nobr> before <tr>
line 147 column 35 - Warning: missing <tr>
line 147 column 50 - Warning: missing </font> before </td>
line 148 column 37 - Warning: unescaped & or unknown entity "&id"
line 147 column 180 - Warning: missing </font> before </table>
line 149 column 35 - Warning: missing <tr>
line 149 column 96 - Warning: unescaped & or unknown entity "&page"
line 149 column 50 - Warning: missing </font> before </td>
line 149 column 131 - Warning: missing </font> before </table>
line 156 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 158 column 9 - Warning: missing <tr>
line 176 column 13 - Warning: missing <tr>
line 226 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 228 column 9 - Warning: missing <tr>
line 246 column 13 - Warning: missing <tr>
line 249 column 312 - Warning: missing </font> before <hr>
line 249 column 689 - Warning: discarding unexpected </td>
line 252 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 254 column 9 - Warning: missing <tr>
line 272 column 13 - Warning: missing <tr>
line 275 column 74 - Warning: <style> isn't allowed in <td> elements
line 275 column 9 - Info: <td> previously mentioned
line 275 column 1365 - Error: <z> is not recognized!
line 275 column 1365 - Warning: discarding unexpected <z>
line 275 column 1377 - Warning: discarding unexpected </z>
line 277 column 1409 - Error: <z> is not recognized!
line 277 column 1409 - Warning: discarding unexpected <z>
line 277 column 1417 - Warning: discarding unexpected </z>
line 279 column 1433 - Error: <z> is not recognized!
line 279 column 1433 - Warning: discarding unexpected <z>
line 279 column 1445 - Warning: discarding unexpected </z>
line 281 column 1461 - Error: <z> is not recognized!
line 281 column 1461 - Warning: discarding unexpected <z>
line 281 column 1469 - Warning: discarding unexpected </z>
line 285 column 2615 - Warning: discarding unexpected </td>
line 288 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 290 column 9 - Warning: missing <tr>
line 308 column 13 - Warning: missing <tr>
line 311 column 74 - Warning: <style> isn't allowed in <td> elements
line 311 column 9 - Info: <td> previously mentioned
line 312 column 1387 - Warning: replacing unexpected font with </font>
line 317 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 319 column 9 - Warning: missing <tr>
line 337 column 13 - Warning: missing <tr>
line 340 column 243 - Warning: missing <tr>
line 340 column 491 - Warning: missing <tr>
line 343 column 1178 - Warning: unescaped & or unknown entity "&theme"
line 346 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 348 column 9 - Warning: missing <tr>
line 366 column 13 - Warning: missing <tr>
line 369 column 74 - Warning: <style> isn't allowed in <td> elements
line 369 column 9 - Info: <td> previously mentioned
line 370 column 1315 - Warning: replacing unexpected font with </font>
line 375 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 377 column 9 - Warning: missing <tr>
line 395 column 13 - Warning: missing <tr>
line 420 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 422 column 9 - Warning: missing <tr>
line 440 column 13 - Warning: missing <tr>
line 450 column 9 - Warning: <div> isn't allowed in <table> elements
line 152 column 17 - Info: <table> previously mentioned
line 452 column 9 - Warning: missing <tr>
line 470 column 13 - Warning: missing <tr>
line 473 column 74 - Warning: <style> isn't allowed in <td> elements
line 473 column 9 - Info: <td> previously mentioned
line 473 column 1365 - Error: <z> is not recognized!
line 473 column 1365 - Warning: discarding unexpected <z>
line 473 column 1377 - Warning: discarding unexpected </z>
line 475 column 1409 - Error: <z> is not recognized!
Tidy found 361 warnings and 8 errors! Not all warnings/errors were shown.

The alt attribute should be used to give a short description
of an image; longer descriptions should be given with the
longdesc attribute which takes a URL linked to the description.
These measures are needed for people using non-graphical browsers.

For further advice on how to make your pages accessible
see http://www.w3.org/WAI/GL.
You are recommended to use CSS to specify the font and
properties such as its size and color. This will reduce
the size of HTML files and make them easier to maintain
compared with using <FONT> elements.

You are recommended to use CSS to control line wrapping.
Use "white-space: nowrap" to inhibit wrapping in place
of inserting <NOBR>...</NOBR> into the markup.

About HTML Tidy: https://github.com/htacg/tidy-html5
Bug reports and comments: https://github.com/htacg/tidy-html5/issues
Official mailing list: https://lists.w3.org/Archives/Public/public-htacg/
Latest HTML specification: http://dev.w3.org/html5/spec-author-view/
Validate your HTML documents: http://validator.w3.org/nu/
Lobby your company to join the W3C: http://www.w3.org/Consortium

Do you speak a language other than English, or a different variant of
English? Consider helping us to localize HTML Tidy. For details please see
https://github.com/htacg/tidy-html5/blob/master/README/LOCALIZE.md